Another UI suggestion

In the SystemBrowser double clicking on a package currently does
nothing.  It would be nice, and seem quite natural, if it opened up a
PackageBrowser with the correct folder and package selected.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:ZE08c.25920$Y%[hidden email]...
> In the SystemBrowser double clicking on a package currently does
> nothing.  It would be nice, and seem quite natural, if it opened up a
> PackageBrowser with the correct folder and package selected.

Agreed. I ran into that surprise myself the other day, assuming it would do
just that. Recorded as #1532.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:c3rvls$298pj8$[hidden email]...
> "Ian Bartholomew" <[hidden email]> wrote in message
> news:ZE08c.25920$Y%[hidden email]...
> > In the SystemBrowser double clicking on a package currently does
> > nothing.  It would be nice, and seem quite natural, if it opened up a
> > PackageBrowser with the correct folder and package selected.
>
> Agreed. I ran into that surprise myself the other day, assuming it would
do
> just that. Recorded as #1532.

Ian, looking into this a bit further I found that the reason for the
surprise is that the package selector is using the double-click action for
another purpose, which is to refocus the filter tree to the folder
containing the chosen package. Of course this doesn't do anything if the
tree already has that folder selected. I think the idea here is that one can
"drill down" by double clicking the package. Is this useful functionality?
Yes, I think so. I have used it on occassion. Does it warrant taking away
the normal use of double-clicking something as "choosing" it (and requesting
that the default editing action be performed on it, or that it be selected
if one is in a dialog)? No, I don't think so, especially in a package
selector dialog since normally one would expect to be able to make a choice
from such a dialog by a double-click, rather than a selection and pressing
the OK button.

Some relevant history from the 5.0 beta programme:

#475: Double click/Ctrl+B package in system browser should open package
browser on that package (Chris Uppal)
    "Choosing a package in the system browser (double click), or activating
the Browse-It command when a package is selected and focus is with the
package list, should open a package browser on that package."
    The fix notes for this indicate that there is a clash with the filter
synchronisation, so only the Ctrl+B action was enabled.
#524: Double click/Enter in Package Browser package list should sync. folder
tree to package's containing folder (Ian Bartholomew!)
    "With folder $ selected double clicking a package would open the folder
tree to the appropriate folder and reselect the package."

Personally I think that for the sake of consistency that the double-click
action should be reserved for the "choice" action, and that the synchronise
operation should be done some other way (there is already a context menu
command for it). Obviously this is not what we thought at the time of the
5.0 beta. What do you, Chris, and others think now?

Regards

Blair

Blair,

> Personally I think that for the sake of consistency that the
> double-click action should be reserved for the "choice" action, and
> that the synchronise operation should be done some other way (there
> is already a context menu command for it). Obviously this is not what
> we thought at the time of the
> 5.0 beta. What do you, Chris, and others think now?

Of the two options I think I would prefer double-clicking a package in the
SystemBrowser to open up a PackageBrowser on the selected package and leave
the synchronise function to a menu option and, possibly, hot key. For
consistency I suppose the PackageBrowser should do the same thing but it's
difficult to see any useful action that could be performed when a package is
double clicked there - maybe opening up the properties inspector?

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Blair,
"Ian Bartholomew" <[hidden email]> wrote in message
news:c4e98k$2hqdpo$[hidden email]...
[...]
> Of the two options I think I would prefer double-clicking a package in the
> SystemBrowser to open up a PackageBrowser on the selected package and
leave
> the synchronise function to a menu option and, possibly, hot key. For
> consistency I suppose the PackageBrowser should do the same thing but it's
> difficult to see any useful action that could be performed when a package
is
> double clicked there - maybe opening up the properties inspector?

FWIW, I second this.  It seems to me that the relationship between packages
and folders in the SystemBrowser is analogous to the one between methods and
categories (although it's more strictly hierarchical).  The method browser
and category panes interact in a way that strikes me as pretty intuitive.
If you have a method selected, changing to any other category that includes
that method allows you to see other methods in the category without losing
the selection.  Of course, that sort of behavior might involve a fair amount
of work, and I'd certainly rather have v6 without it if it entailed any sort
of delay ;^).

Don

Blair McGlashan wrote:
> Personally I think that for the sake of consistency that the double-click
> action should be reserved for the "choice" action, and that the synchronise
> operation should be done some other way (there is already a context menu
> command for it). Obviously this is not what we thought at the time of the
> 5.0 beta. What do you, Chris, and others think now?

I concur that the double-click should be the "choice" action.

On a related note, a few comments or suggestions on the package / folder
synchronization operation.

It seems that selecting the "back" button to go to a previously visited
method unfortunately ends up doing the folder sync even when the class
in question is already showing in the selected folder. This is so
annoying that it pretty much keeps me from using the "back" function.
I'll typically select the folder in the hierarchy that covers the
related group of packages that I'm working on, and then want to leave it
alone for long periods of time. I'd much rather if the back function
could leave the folder and/or packages selection alone (whenever it can)
when jumping to a previous class/method.

What to do when jumping to a class not currently visible? The current
mechanism of selecting the owning package and most restrictive folder
would work. But I'd prefer a more inclusive approach, that would move to
the folder that was in common with where I was and the target class.
With the selection acting more like what's outlined below.

I'd also like to see package selections left alone (as much as possible)
when selecting a different folder, rather than the current behavior of
selecting all the packages. One can easily enough get all the packages
with the ctrl-A shortcut. A typical scenario might be where 3 related
packages are selected and one might then want to change the focus
somewhat by either going higher or lower in the folder hierarchy. It
would be really nice if those same 3 packages were still selected when
moving higher (to a broader context). One could for example then add an
additional package to the selection and continue working without having
to find and re-select all the packages of interest all over again. When
moving lower in the hierarchy it would retain selections on the packages
that it could.

Hope none of this sounds like grousing! I think that Dolphin is a great
product. Just trying to help make it a little better. I guess I'm always
looking for a better way of keeping my "working" set of packages and
classes ready to hand during a development episode. Perhaps what's
really needed is some drag/drop configurable browser? StarBrowser,
http://homepages.ulb.ac.be/~rowuyts/StarBrowser/index.html, looks pretty
interesting, though I haven't actually tried it yet. I wonder how hard
it would be to port?

regards,
-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Blair McGlashan wrote:

> Personally I think that for the sake of consistency that the double-click
> action should be reserved for the "choice" action, and that the
> synchronise operation should be done some other way (there is already a
> context menu command for it). Obviously this is not what we thought at
> the time of the
> 5.0 beta. What do you, Chris, and others think now?

I agree.

    -- chris