A few UI suggestions

Here are some suggestions which I think would (further) enhance the IDE's
UI.  I'm sorry the list is so long.  I hadn't realised how many of these
things I'd got backed up until I started writing.

Make it possible to cancel a drag-n-drop operation by pressing ESC.  This is
important for laptop users (this one anyway) since it is very easy to start
a D&D by accident.

Give items in the SmalltalkSystemShell folders a right-button menu with a
"P&roperties..." item.  If the object has options (in the sense of having
used SmalltalkSystem class>>registerTool: -- and most of them have) then
this command would open an appropriate PAE.

Give the package icon in the CHB's status bar the same context menu as a
package has in the package browser.  Save and Save changes would be
particularly useful, I think.

Also about the package icon in the CHB: if the class isn't in any package,
then double clicking could bring up a package selection dialog.  The current
behaviour -- opening a CHB on UndefinedObject -- is less useful that it
could be ;-)

Add a new top-level menu of the System Folder from which we can browse for
methods.  (it's currently rather frustrating to have to open a CHB, select
Method=>Browse=>Containing text just to look for all methods with the
text -- especially when the new CHB won't actually be used to browse the
methods).

In the MethodBrowser, add the option to browse references/definitions of
selectors in the same package.

I'd also like to see browsing options added to the PackageBrowser -- e.g.
I'd like to be able to select a package and browse all definitions of a
selector within it.

Am I the only Dolphin user who keeps trying to change a class's name with
F2 ?  And trying to delete methods/classes/etc with DEL ?

It's currently awkward to change the name of a method, especially if it's a
loose method.  We have to change the name in the edit window, save (accept)
it, then find the old method and delete that.  If it was a loose method then
we also have to change the owning package of the new method.  (And, if
you're as obsessive about package's changed flags as I am, go and remove the
flag from the package that the new method was briefly added to).  It'd be
nice to have an option like "save-replace" which would do all this for us
(VA Java has something similar, which I like and use a lot).

Make the "delete" operation in the ViewComposer use 'D' as it's accelerator
instead of 'L' -- it's inconsistent with every other Dolphin delete menu
command.  (I know I've mentioned this a couple of times before; I can be
irritatingly persistent sometimes ;-)

(This one's a bit speculative) Make the class-tree pane of the CHB into a
tabbed window.  One tab would be the class tree just as at present.  Another
would be an alphabetical list of all classes.  The third would be another
tree, this one has class categories at its roots (and for as far down as is
needed by the '-' convention), and then have alphabetical lists of the
classes in that category hanging beneath.  Of course, one class might appear
in several different lists -- I don't think that's a problem for the UI.  My
main concern with this is that it may seem inconsistent with the way that
method categories and methods are displayed.  However the middle-top pane of
the CHB is a *filter* pane (and, indeed, I'd like to see more filtering tabs
added to it, such as the general "dropping filter" I posted a year or so
ago), whereas the class pane could be seen just as three different ways of
organising the presentation of the same list of classes.

Thoughts ?

    -- chris

Chris

You wrote in message
news:[hidden email]...

>...[enhancement suggestions snipped]...

Thanks for all your suggestions. I have added them all to the Bugs DB for
inclusion in future versions.

I'll just comment on a couple:

> ...
> It's currently awkward to change the name of a method, especially if it's
a
> loose method.  We have to change the name in the edit window, save
(accept)
> it, then find the old method and delete that.  If it was a loose method
then
> we also have to change the owning package of the new method.  (And, if
> you're as obsessive about package's changed flags as I am, go and remove
the
> flag from the package that the new method was briefly added to).  It'd be
> nice to have an option like "save-replace" which would do all this for us
> (VA Java has something similar, which I like and use a lot).

I agree that this would be very useful - I frequently rename methods to add
new parameters, or until I get the name right. However I think it might be
better done by having a "rename" capability in the method list panes. The
Refactoring Browser has the ability to do this (and to rename a method
globally too). The D5 under development has these features.

> (This one's a bit speculative) Make the class-tree pane of the CHB into a
> tabbed window.  One tab would be the class tree just as at present.
Another
> would be an alphabetical list of all classes.  The third would be another
> tree, this one has class categories at its roots (and for as far down as
is
> needed by the '-' convention), and then have alphabetical lists of the
> classes in that category hanging beneath.  Of course, one class might
appear
> in several different lists -- I don't think that's a problem for the UI.
My
> main concern with this is that it may seem inconsistent with the way that
> method categories and methods are displayed.  However the middle-top pane
of
> the CHB is a *filter* pane (and, indeed, I'd like to see more filtering
tabs
> added to it, such as the general "dropping filter" I posted a year or so
> ago), whereas the class pane could be seen just as three different ways of
> organising the presentation of the same list of classes.

Actually we've been thinking that the Class Categories ought to go
altogether, since these are arguably just a poor mans packaging mechanism.
Yes I know that Dolphin's support for multiple class categories mean that
they give the opportunity to have classes appearing in multiple slices
across the hierarchy, but I'm just not sure that this actually makes the
categories useful enough to justify their existence. I'm willing to be
persuaded otherwise though.

Of course the same idea could well be applied to packages. The ability to
filter by package will definitely be a feature of the next release, and the
presentation of packages will be revised to be hierarchical (e.g. so that
all Samples appear collected together), with the hierarchy being based on
the path.

Regards

Blair

Blair,

>> [about renaming methods]
> I agree that this would be very useful - I frequently rename methods to
add
> new parameters, or until I get the name right. However I think it might be
> better done by having a "rename" capability in the method list panes.

That would be great.  I look forward to it.

>> [about browsing by class category]
> Actually we've been thinking that the Class Categories ought to go
> altogether, since these are arguably just a poor mans packaging mechanism.

I admit that I don't use the categories at all.  But then, is that because
there is no real tool support ?  I don't know.  What do people who use tools
which do present classes by category think ?  Is this something that's
useful and missing in Dolphin ?  Or does it just add clutter ?

I'd be sorry to see you *remove* the feature though -- I think it's
important to be able to maintain as much information as possible when
sharing code between dialects.  If you removed support for categories (and
presumably dummied-out the relevant methods), then it'd be difficult to do
round-trip porting, from VW (for the sake of argument), into Dolphin, and
then back to VW.  I think that maintaining as much info as possible (even if
not used by the current IDE) to support such round-tripping is important.

> Blair

    -- chris

On Sun, 13 May 2001 09:48:38 +0100, "Chris Uppal"
<[hidden email]> wrote:

I'm very confused about how I feel about classes by category.  When
I'm working in Squeak I wish classes were in a hierarchy instead of
categories, and when I'm working in Dolphin I wish classes were in
categories instead of a hierarchy!  I think the RefactoringBrowser
(RB) can switch between viewing classes in a hierarchy or in
categories.  I just installed Donald MacQueen's GUI and I'll have to
check if it supports this yet and if it helps.

Thank you Donald.

Now I have to actually learn how to use all the RB power since I
finally have it in a version I work in.


>
>I'd be sorry to see you *remove* the feature though -- I think it's
>important to be able to maintain as much information as possible when
>sharing code between dialects.  If you removed support for categories (and
>presumably dummied-out the relevant methods), then it'd be difficult to do
>round-trip porting, from VW (for the sake of argument), into Dolphin, and
>then back to VW.  I think that maintaining as much info as possible (even if
>not used by the current IDE) to support such round-tripping is important.

I also think it is important to preserve as much info as possible.

To this end in my reworked version of Eric Arsenau's SIF 2.0 I
experimented with keeping unused annotations (class or method
category, author, comment, revision history, etc.) as a property of
the Smalltalk object created when filing in.  This was simple and
effective but brittle.

The easiest brittle case is a method.  Compile the method from the SIF
source, add the unsupported annotations as properties of the compiled
method, later modify the method, and whoops, the unsupported
annotations properties are gone along with the old compiled method.

I decided remove the experiment and to leave this as a future
enhancement since the reworked version was already such a major
revision.  I not sure if the approach I tried is usable with the
addition of relevant notifications, but it seems OK.

Originally I envisioned a different approach that leveraged off the RB
model of a program.  I think this is ultimately the most powerful and
portable approach.  But I need to learn a lot more about the RB.  I
actually had a model of a program in the first SIF version I released
a year or more ago.  I was doing round trip from Squeak to Smalltalk
Express (SE) with class and method categories maintained intact.  The
base SE has neither class or method categories.

My reworked version of Eric Arseneau's SIF 2.0 allows dialect specific
working units to be filed in and out in SIF.  These are so far:

        Dolphin         - a package (.pac file).
        Squeak          - a change set at least in 2.7 (.cs file).
        Visual Age      - Don't know? an Application?
        VisualWorks     - a parcel I think (.pcl file)?

This allows one to work using the tools in each dialect, but easily
load and store the work produced in any dialect.   Eric SIF is
available for Dolphin, Squeak, VA, and VW, and other dialects.

My experiment in keeping unused annotations could easily be added back
in.  I kept the dialect independent properties stuff in the
Portability Project layer on top of ANSI Compatibility Project layer
as it is very useful as a substitute to adding new variables to an
existing class.  Unused annotations only requires a couple (1-3?) of
extra methods and a couple of additional lines of code in the SIF file
in and out methods.

This would, I think, make round-trip porting, from VW (or any
dialect), into Dolphin, and then back to VW almost (other issues)
painless.

--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

Blair McGlashan wrote:

> Actually we've been thinking that the Class Categories ought to go
> altogether, since these are arguably just a poor mans packaging mechanism.

Say it isn't so!!!!

The only thing I really dislike about Dolphin (and I've been busily
disliking it since version 2) is the lack of a class category pane in
the browser. I learnt Smalltalk on VW, and grew very dependent on the
SmartBrowser or whatever it was called - basically a browser with class
categories in the left hand pane.

I've been hoping for ages that the next version of Dolphin would finally
allow this, as for me it's the obvious and natural way to search for
classes and to organise the classes I write. Browsing by heirachy is
fine a lot of the time and I'd *HATE* to see it go - but then, the ideal
browser would have a button to toggle the left hand pane between
category and heirachy.

Yes, the package browser is better than nothing, but:
        - it's too coarse grained for the core Dolphin classes (though good for
add ons)
        - it's not hierachical which (I think) the categories are
        - it's not integrated into the browser the way the trusty left pane is

Oh yeah  - the other browser enhancement I miss from VW is a toggle to
make the right hand pane show either all of the methods a class
implements (the normal case) or all of the methods the class and all its
superclasses (except Object which is too big) implement. Very often I
want to be able to look through a class and see what it can do - as
opposed to what it can do that its superclass can't.

If Dolphin supported these two features, it really would be fantastic to
use.

> Blair




                                        Steve

Chris Uppal wrote:

> I admit that I don't use the categories at all.  But then, is that because
> there is no real tool support ?  I don't know.  What do people who use tools
> which do present classes by category think ?  Is this something that's
> useful and missing in Dolphin ?  Or does it just add clutter ?

Coming from a VW background I used to use this every day and I sorely
miss it in Dolphin. And yes, without real tool support they don't offer
anything useful - buy surely that means we need real tool support, not
that we should throw them away? Please. Whimper.

>     -- chris



                                     Steve

Steve,

>             . Very often I
> want to be able to look through a class and see what it can do - as
> opposed to what it can do that its superclass can't.

If you're using D4 then selecting Class/Browse/All methods in the CHB (it's
on the context menu as well) gives you this information, although it does
also include the methods implemented in Object.

Ian

Ian Bartholomew wrote:

> If you're using D4 then selecting Class/Browse/All methods in the CHB (it's
> on the context menu as well) gives you this information, although it does
> also include the methods implemented in Object.

Oh excellent. Though I bought D4 when it came out, I haven't had any
time at all to use it yet. I look forward to it.

> Ian



                                   Steve

"Steve Taylor" <[hidden email]> wrote in message
news:[hidden email]...
> Blair McGlashan wrote:
>
> > Actually we've been thinking that the Class Categories ought to go
> > altogether, since these are arguably just a poor mans packaging
mechanism.
>
> Say it isn't so!!!!
>
> The only thing I really dislike about Dolphin (and I've been busily
> disliking it since version 2) is the lack of a class category pane in
> the browser. I learnt Smalltalk on VW, and grew very dependent on the
> SmartBrowser or whatever it was called - basically a browser with class
> categories in the left hand pane.
>

So many people, so many opinions. Because of the categories, I can't find my
way in the standard VW browser, so please Blair, don't enforce the
categories upon us.......

But what about namespaces......

Ted

"ted.bracht" wrote:

> So many people, so many opinions. Because of the categories, I can't find my
> way in the standard VW browser, so please Blair, don't enforce the
> categories upon us.......

I can see that - heirachies can be good too. But what about a switch to
toggle the left pane of the browser between heirachy and category? That
should make everybody happy - except the poor buggers who have to
implement it.

> Ted



                                                  Steve