Re: Tasklist UI issues

Tor Norbye said:
>
> *Issue 1*:
> *Recommendation*: For release 1.0, just bring up the confirmation dialog
> for each suggestion in succession. Use the "Fix All" button to allow
> users skip the confirmation step for the remaining suggestions.
>

I think that your recommendation is the best solution to this
problem. Remember that it was the user that selected all of the nodes
in the first place, and I can't see why the user should select all
nodes one again (In norwegian I would probably use the term "smør på
flesk"). One could perhaps argue that if the user selected all of the
top-nodes with the tree collapsed, it would be nice to be able to
deselect one (or more) toplevel nodes...


> *Issue 2*: As you can see from the confirmation dialog screenshot, there
> is a checkbox named "Skip confirmation next time". When the user checks
> this, the user is never prompted again for suggestions of this type -
> they are simply performed.
>
>    1. Should I have a "Stop making suggestions of this type" checkbox as
>       well, making it easy to get rid of suggestions of a particular
>       type?
>
>       *Recommendation*: No. It's easy enough to do this from the context
>       menu: simply right click on a suggestion and select "Disable
>       Type". If you change your mind, select "Re-enable Types >" which
>       is a pullright menu containing a list of the suggestion types
>       which have been disabled.
>

I agree with you here...

>
> *Issue 3*: Should I add a "Fix All" action on category nodes so that you
> can easily operate on a set of suggestions without needing to make a
> selection (which often involves scrolling when there are lots of them?).
>
> Because of issue 1, this would only produce a confirmation dialog
> stating that all suggestions will be performed (to give you a chance to
> cancel) and perhaps list the summaries for each with checkboxes to let
> you unselect some. Also, suggestions for this category that do not have
> associated fixes (for example, because it cannot be done safely; for
> example, an unused field on a line containing method calls will not have
> an associated fixer since the unused method could have an important side
> effect.)
>

You should definitively show a confirmation dialog where the user may
select/deselct the items to fix. As you said, it may be a lot of
items, with some outside the "current view"...


> *Issue 4*:
> Some solution ideas:
>
>     * What I have now: a different icon for solution suggestions, which
>       hopefully draws you attention to them.
>     * (*My favorite*) Nest solutions as subnodes of the problem item

I like the last one best... The error itself is the top node, and the
various solutions is child nodes... This way I can have a compact
view, and it does not change that much when you add a new "error"
(only one line instead of 'n'). (it's only when i "inspect" that
specific error that I am interested in the various suggestions you may
have...)

>
> *Issue 5*:
> Is that a reasonable visual cue? I wanted to make the current line bold,
> but well, take a look at the nbdev discussion on this (rendering hints,
> started by Tim B.)

I did not find the icon intuitive at once, but I migth get used to it ;)

>
> *Issue 6*: For PMD rules in particular, I tend to get LOTS of rule

[ cut ]

> And possibly, if there are less than N suggestions of a particular
> subtype (where I propose N=3), they are "inlined" at the top type level,
> e.g.
>
>   - Rule Violations
>     - Unused Imports (3)
>          Unused import: Avoid unused imports such as 'HashSet'
>          Unused import: Avoid unused imports such as 'Map'
>          Unused import: Avoid unused imports such as 'File'
>       UnusedLocalVariable: Avoid unused local variables such as 'xyz'
>       OnlyOneReturn: A method should only have one exit point

I would only inline them if it is only _one_ item...

>
> *Issue 7*: Let's say I allow subtypes as proposed above. How does this
> show up elsewhere, for filtering and disabling types?
>
> http://tasklist.netbeans.org/suggestions_v2_popup.gif

The transparent windows may look nice on your desktop, but you should
probably not use them for screenshots... It took me a while to
understand that it _was_ a transparen window ;)

>
> *Issue 8*:
> In other words, should the suggestions window reflect the current,
> edited state of the document, or the on-disk, saved state of the
> document?
>

I think that the suggestions should reflect the state of the document
in the editor. (on the other hand, I hate that something "happens" on
my screen on another location than the cursor, since my eyes
automatically moves there..)


> *Issue 9*: I'm showing "category nodes" for the types of suggestions.
> What should happen if the number of suggestions of a particular type
> goes down to 0 - should I remove the category node from the display as
> well? For example, this easily happens if you're looking at a file with
> compilation errors and then switch to a different file. Should the whole
> javac compiler error node disappear or simply have no children?
>
> *Recommendation*: For now I'd like to leave it there. It's an easy
> implementation way to ensure that the collapse/expand state of a type is
> preserved, and that the relative order of the types do not change as you
> traverse files in the editor.

I agree that you should leave it there... you could alternatively
remove it when the user press the save button or something like
that (since the user changed the "state" of the document....)

>
> *Issue 10*:
>
> So the question is what I do about this. Should I perhaps have a
> confirmation dialog which lists the lines surrounding the field (with
> checkboxes for each) letting you choose how much should get deleted?

That would probably be nice ;)

>
> *Issue 12*:

> Other IDEs have a single tasklist where all this (compiler errors, user
> tasks) appear in a single window. Should we make it possible to add user
> actions in this view as well? How high a priority is that? And if so,
> should we change the name of the window to "Tasks" instead of
> "Suggestions" ? (The fact that I'm listing both compiler errors, and
> tasks scanned from source code (// TODO and so on) already makes this
> relevant I think.
>

What about adding the users default tasklist as a toplevel node?


> *Issue 13*:

> Right now if you click on the Suggestions View icon it will only open or
> front the existing one, not create additional instances. Is that the
> right way to do this, or is there a better way? (A "New" item in the
> View's context menu, etc.)
>
> *Recommendation*: I'd like to push this out to version 1.1.

I don't think that I would utilize such a feature ;)


>
> *Issue 14*:

> Is there a better heuristic to use here? Hardcode that java compiler
> errors is "special" and make it expanded by default, all others
> collapsed? Make the APIs such that a provider can declare itself
> "important"? Use suggestion priority to decide whether a category should
> be expanded: true whenever there is one or more suggestions with
> priority high in that category? Other ideas?
>

I don't think I like the idea that some nodes are default open and
some not (it makes the IDE inconsistent in my eyes). If possible you
could perhaps try to "leave the tree as it was".. By that I mean that
if the java compilation errors was expanded when you opened another
file, then the node should be expanded in the new file..


> *Issue 15*:

> *Recommendation*: Files that were already open in the IDE should not be
> saved. Any files that are "opened" only to apply a fix should be saved
> immediately after applying the fix.

But they should not be closed, otherwise you don't have the
opportunity to undo the changes....

Well that's just my opinion...

Trond