SystemBrowser

I mentioned this before but I've had another thought so I thought I'd bring
it up again.

I like the SystemBrowser but I find the inability to look at loose methods
in a package is a bit of an annoyance. I was wondering if something could be
added (i.e. I haven't looked into if/how it could be done :) ) so that if a
package (or packages) was selected, but without a class being selected, then
the methods list could show the loose method(s) defined in the package(s).
These selectors could be shown dimmed so that they couldn't be directly
edited but would be easily accessible, without having to go back to the PB
every time.

Just a thought

Ian

Ian wrote:

> I like the SystemBrowser but I find the inability to look at loose methods
> in a package is a bit of an annoyance. I was wondering if something could
be
> added (i.e. I haven't looked into if/how it could be done :) ) so that if
a
> package (or packages) was selected, but without a class being selected,
then
> the methods list could show the loose method(s) defined in the package(s).
> These selectors could be shown dimmed so that they couldn't be directly
> edited but would be easily accessible, without having to go back to the PB
> every time.

Just a couple of follow-on thoughts.

Now that the _Undefined package is becoming more of a foreground object
(appearing in lists in the GUI and so forth), would this be a good time to
change its name to something that *can't* clash with a filesystem name ?
Say "<no package>".  It's obviously not worth bothering about if it'd take
more than a couple of minutes to change.

More substantially (but also more speculative).  There's something I find
odd or unnatural about the System Browser (SB) -- other than the selection
mechanism that we've all complained about.  Maybe it's just that I'm not
used to a non-hierarchical presentation of the classes, but I find that just
seeing a class without its superclasses leaves me feeling uneasy.  I'm only
getting part of the picture; sort of like driving without a rear view
mirror.  I get the same feeling with non-hierarchical browsers in other
Smalltalk flavours.  (Of course, the show inherited methods option helps,
but is not completely satisfactory).

Anyway, out of that feeling, and Ian's related problem.  Here's a proposal
(which is probably too complex to make it into this release, even if you do
like the idea):

Change the class list to a tree.  Classes are included in the tree if and
only if at least one of the following applies:

    - the class is part of the selected packages
    - the class has a loose method from one of the selected packages
    - the class is a superclass (possibly indirect) of some other class
which is in the tree

Thus Object would always be included, but True (say) would hardly ever show
up in the tree.

Grey out all classes in the class tree which are not themselves part of the
selected packages (so it will have to be some sort of owner-draw tree).
Grey out all methods in the method list which are not themselves part of the
selected packages.

Then the SB becomes just a CHB plus a filter to exclude irrelevant classes
without excluding the information needed to understand the selected classes
and methods.

You could take this one step further.  Now that the CHB and SB are so alike,
the two can be merged again.  If you put the package list/filter into a
separate tab "behind" the class tree, and make the initial filter be "show
everything", then a CHB is just a SB with the default filter.  I think that
would be worthwhile simplification and generalisation.

I did once put something together for D4 which was rather like this idea
(but without the owner draw stuff).  It used a concept of a "project" which
was a collection of packages and other projects.  I added a project list in
a new tab behind the class tree of a standard CHB, which acted as a class
filter in much the way that the SB does it.  I only spent a couple of hours
putting it together (I did it mainly to irritate a college who was running
on and on about how flexible "Netbeans" -- the Java IDE -- was, but
bemoaning the fact that it didn't have the ability to filter the classes by
project.  I set my self the task of adding something similar to Dolphin
before lunchtime to show him what "flexibility" really means).  It worked
rather well, given the constraints.  In particular, putting the filter on a
separate tab from the classes saved screen space and did *not* feel clumsy.

(Incidentally I find the SB too cramped to use on a 1024x768 screen --
which, barring improvements in flat screen technology is all you get on a
physically small notebook -- so I think there's something to be said for
using a tabbed view to give more space to both the class list and the
package tree, even if you don't like the above idea.  Of course that's
something that I can hack in moderately easily myself if you don't care for
it).

    -- chris

Chris,

Just a few inline comments...

> used to a non-hierarchical presentation of the classes, but I find that
just
> seeing a class without its superclasses leaves me feeling uneasy.  I'm
only
> getting part of the picture; sort of like driving without a rear view
> mirror.

I get the same feeling of something missing but I find that the lack of an
immediate hierarchical view, which can be obtained by double clicking on a
class anyway, is easily outdone by the advantage of having all the classes
in a package available immediately, without scrolling or having to open tree
nodes.  I've been finding that the "programming experience" seems to be much
smoother using the SB.

> Anyway, out of that feeling, and Ian's related problem.  Here's a proposal
> (which is probably too complex to make it into this release, even if you
do
> like the idea):
[browser description snipped]

With the refactoring of the browser hierarchy I think that adding new
browsers, especially ones that just present the existing model in a
different way, should be much easier. Maybe it's not a case of replacing the
SB and CHB but adding an additional one - providing a sort of "Take Your
Pick". Perhaps a good opportunity for Goodies writers :)

> (Incidentally I find the SB too cramped to use on a 1024x768 screen --
> which, barring improvements in flat screen technology is all you get on a
> physically small notebook --

One of the first things I do is drag the splitter to make the class list
wider. [1]  I do tend to use full screen more than I did using the CHB
though.

Regards
    Ian

[1] I also tried modifying the splitter class so a left double click on it
reduced the view on the splitter's left down to a 1/4 of it's original width
and double right click increased it by 4 times.  I found dragging was just
as easy though.

On Sat, 23 Feb 2002 12:26:53 -0000, "Chris Uppal"
<[hidden email]> wrote:
Chris,

I was blue skying on this very idea this morning. I think the SB is very close
to being the swiss army knife of browsers. As is,  it almost completely
removes the need to open the PB or CHB. Having the class pane be a tree would
eliminate the CHB for me.

But how to show the hierarchy? Here is the blue sky part. Consider the classes
shown in the class pane. If you were looking at a regular tree pane, those
would be "roots". Normally when you click on a root, you see branches and
leaves.
But in this instance, those classes are logically really "leaves". What if you
could just show the "leaves" in a tree, and if you clicked on a leaf, it
expanded UP and showed you the parent branches back to the root (Object)?

I've never seen this interface before but I bet it would work nicely in this
situation.

Another idea, more mundane but maybe even more useful, is one borrowed from
VisualSmalltalk package browsers: Have a drop-down combobox at the top of the
method pane, containing all those class roots. I think this would be better
than the 'show inherited methods' button because you could then select how
much of the hierarchy you want (ie not just all, none, or (all - Object)).
Also its a much simpler interface.

-alan r.

I wrote:

> I did once put something together for D4 which was rather like this idea
> (but without the owner draw stuff).  It used a concept of a "project"
which
> was a collection of packages and other projects.  I added a project list
in
> a new tab behind the class tree of a standard CHB, which acted as a class
> filter in much the way that the SB does it.

Having written that, I (inevitably) ended up porting the thing to D5 and
implementing the owner draw stuff to do the fading (easier than I'd
expected).  I think it's quite nice.  If there's any interest in it as an
example for what a hierarchical SB could be like (I don't expect anyone else
would want to *use* it) then I'll post the code, or a couple of screen
shots.

One thing that has become clear, though, is that the idea of putting the
classes and filters into the same tab-set is OK for saving screen space (and
necessary for me), but is not a Good Thing for the UI since the tabs have a
different relationship to each other compared with other tabsets in the
CHB/SB (which itself is already a little confused, but not badly so).

    -- chris

Ian,

> With the refactoring of the browser hierarchy I think that adding new
> browsers, especially ones that just present the existing model in a
> different way, should be much easier. Maybe it's not a case of replacing
the
> SB and CHB but adding an additional one - providing a sort of "Take Your
> Pick". Perhaps a good opportunity for Goodies writers :)

Yes that's true, and it's a Good Thing.  OTOH, I don't think much of the
plethora of nearly-but-not-quite the same browsers that some of the other
STs have, or had (and VA Java too, come to that).  I find it confusing as a
beginner (very) and inelegant as a more experienced user.  I wouldn't like
to see Dolphin move further in that direction.

>     Ian

    -- chris

Alan,

> But in this instance, those classes are logically really "leaves". What if
you
> could just show the "leaves" in a tree, and if you clicked on a leaf, it
> expanded UP and showed you the parent branches back to the root (Object)?

One problem is that that wouldn't show the relationship between sibling
classes.

E.g. In the (D4) CBH, the way I usually work is to have three or four CHB
instances, each in "local hierarchy" mode, set so that each shows some
smallish group of closely related classes (e.g. one on Set and its
subclasses another on WriteStream and its subclasses -- though in fact they
will show clusters of my own classes much more often).  The effect is that I
can concentrate on the classes I'm interested in *without* loosing the
relationships between them.  That's part of what I want in the putative
hierarchical SB.

> Another idea, more mundane but maybe even more useful, is one borrowed
from
> VisualSmalltalk package browsers: Have a drop-down combobox at the top of
the
> method pane, containing all those class roots. I think this would be
better
> than the 'show inherited methods' button because you could then select how
> much of the hierarchy you want (ie not just all, none, or (all - Object)).
> Also its a much simpler interface.

Turning the CHB/SB's Method->Show Inherited Methods menu item into a
pull-right menu should do the trick quite nicely and would (I think) be nice
to have.  I'd still want to keep the toolbar button -- the button would just
toggle the mode, the menu would do that and fine-tune the level of detail as
well.

There is a problem, though, about how much sense it makes when you can
switch to another class in the same browser.  E.g. you are viewing
Dictionary, and you want all methods to be displayed that are inherited from
Set, but then you point the same browser at Number -- what happens then ?  I
don't think it's an insurmountable problem (what does VisualSmalltalk do ?),
but it adds complexity to the UI and/or the implementation.

> -alan r.

    -- chris

Chris

I presume you're referring (mainly) to the dozens of browsers in ENVY. Although
there is a subtle and well-thought-through logic behind them, I must agree with
you that the choice is overwhelming. Remember, though - the ENVY browsers were
written *long* ago, are quite crufty, and suffer from having too much
functionality implemented in the wrong places.

In the work I did on Ginsu in Squeak (which I've almost finished porting to
Dolphin, BTW) I developed a browser hierarchy which was almost, but not quite,
entirely unlike ENVY. It got a lot done in little code by eliminating
redundancy in the browser hierarchy.

That being said, there's one browser (better said, one view on the system) that
I miss in Dolphin. In ENVY, the CHB has four lists, showing class hierarchy,
packages, protocols, and method selectors. When you choose a class, you cann
see which package it's defined in, and which packages contain methods, etc.

Just my 2 Euro...
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
Krysten Nygaard

Chris,

> Turning the CHB/SB's Method->Show Inherited Methods menu item into a
> pull-right menu should do the trick quite nicely and would (I think) be
nice
> to have.  I'd still want to keep the toolbar button -- the button would
just
> toggle the mode, the menu would do that and fine-tune the level of detail
as
> well.
>
> There is a problem, though, about how much sense it makes when you can
> switch to another class in the same browser.  E.g. you are viewing
> Dictionary, and you want all methods to be displayed that are inherited
from
> Set, but then you point the same browser at Number -- what happens then ?
I
> don't think it's an insurmountable problem (what does VisualSmalltalk do
?),
> but it adds complexity to the UI and/or the implementation.

This exactly why we didn't do it. What does (did) VSE do in these
circumstances?

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Ian wrote:
>
> > I like the SystemBrowser but I find the inability to look at loose
methods
> > in a package is a bit of an annoyance. I was wondering if something
could
> be
> > added (i.e. I haven't looked into if/how it could be done :) ) so that
if
> a
> > package (or packages) was selected, but without a class being selected,
> then
> > the methods list could show the loose method(s) defined in the
package(s).
> > These selectors could be shown dimmed so that they couldn't be directly
> > edited but would be easily accessible, without having to go back to the
PB
> > every time.
>
> Just a couple of follow-on thoughts.
>
> Now that the _Undefined package is becoming more of a foreground object
> (appearing in lists in the GUI and so forth), would this be a good time to
> change its name to something that *can't* clash with a filesystem name ?
> Say "<no package>".  It's obviously not worth bothering about if it'd take
> more than a couple of minutes to change.

Thanks, #675.

> More substantially (but also more speculative).  There's something I find
> odd or unnatural about the System Browser (SB) -- other than the selection
> mechanism that we've all complained about.  Maybe it's just that I'm not
> used to a non-hierarchical presentation of the classes, but I find that
just
> seeing a class without its superclasses leaves me feeling uneasy.  I'm
only
> getting part of the picture; sort of like driving without a rear view
> mirror.  I get the same feeling with non-hierarchical browsers in other
> Smalltalk flavours.  (Of course, the show inherited methods option helps,
> but is not completely satisfactory).
>...

FWIW I agree with you. We've always preferred the hierarchical view, hence
the lack of a "system" browser in Dolphin up to now.

>
> Anyway, out of that feeling, and Ian's related problem.  Here's a proposal
> (which is probably too complex to make it into this release, even if you
do show
> up in the tree.


We certainly thought about doing that, in fact that the approach we first
considered was to add the ability to filter by package to the CHB. However
we weren't quite happy with having lots of nodes in the tree that didn't
actually pass the "filter", but were necessary to maintain the structure. We
also wanted to provide something closer to the 4-list system browser that
users of other Smalltalks systems seemed to miss.

I'm sure it is something we will revisit in the future though.

Regards

Blair

Andy,

> This exactly why we didn't do it. What does (did) VSE do in these
> circumstances?

I don't know about VSE, but one possiblilty would be to move the "cut off"
upwards until a super class of the current class was found.

Incidently, there's a similar ambiguity (not that it causes any problems)
with the current setup when browsing a class that doesn't inherit from
Object.

> Andy Bower

    -- chris

In VSE, when you switch classes, the dropdown is set to the class. Eg, if you
have Dictionary as the class but you pulled down Set in the drop down, then
when you point the browser at Number, the dropdown starts at Number. I like
this interface. I personally prefer to not see the inherited methods by
default.

regards,
alan


On Mon, 25 Feb 2002 09:28:45 -0000, "Andy Bower" <[hidden email]>
wrote:

Joseph,

> I presume you're referring (mainly) to the dozens of browsers in ENVY.

Just for the record, I was mostly thinking of VW -- I'd never even seen a
copy of VASt or ENVY until a couple of weeks ago.

(Oddly, it's a side effect of IBM discontinuing VAJ that I've got my hands
on a copy now.  They've converted my VADD subscription into some
significantly more expensive option that normally would be far too much for
my budget, which includes loads of unwanted stuff like WebSphere and DB2,
but also (lo!) a non-commercial copy of VASt enterprise.)

> Joseph Pelrine [ | ]

    -- chris


> "Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
> Krysten Nygaard

What on earth was a Swede doing sober at such a time and date ?

;-)

Blair,

A few reflections:

> [...] However
> we weren't quite happy with having lots of nodes in the tree that didn't
> actually pass the "filter", but were necessary to maintain the structure.

Well, I don't think you can have it both ways -- either you display the full
structure (and so get full information, but at the cost of extra -- but not
extraneous -- nodes) or you don't.

The greying out seems to work pretty well; as I've said, you (or anyone) are
welcome to try my  Project Browser if you'd like to get a hands-on feel for
a filtered hierarchy.

Thinking about Ian's point (statement, claim, confession, whatever ;-) that
he finds that the new SB gives him  a "much smoother" programming
experience, when I am finding quite the reverse.  I wonder if it's dependent
on the progamming style in use at the time.

If the problem is such that the natural approach has a reasonably small
number of more-or-less independent classes (all either subclassing Object,
or some well-known class like Presenter) then the linear presentation may be
optimal.  If, otoh, the solution is one that makes use of lots of classes
arranged such that their inheritance is central to their function (using a
lot of polymorphism, for instance) then the linear approach doesn't work at
all, and the hierarchical presentation is pretty much a necessity.

So it may depend on the problem domain (and the programmer too, I suppose --
but I don't think that Ian's style and my own are inherently all that
different) whether either is even usable, let alone ideal.

As it happens, just about everything I'm doing just now has lots of little
classes, so I don't get on at all with the linear presentation.  Ironically,
the exception is the Project Browser (which I've been sprucing up a
little) -- it's main window is a subclass of the CHB so it's inconveniently,
and un-illuminatingly, far down on one of the branches below Presenter.

> We also wanted to provide something closer to the 4-list system
> browser that users of other Smalltalks systems seemed to miss.

In one ideal world the four panes might be:

1)  Tabbed list of different kinds of class filter -- by package list, by
package tree, by category (possibly), etc.  The point is that the list of
filter-types would be user extensible, so that, e.g, I could plug my
"project" concept into it if I had the inclination.

2) List of classes satisfying the current class filter, presented either as
a tree or as a list according to user choice.  The greying out technique
would be used where appropriate.  (Probably a tabbed pane too.)

3) Tabbed list of different kinds of method filter -- by category, by
package, by instvar, by protocol.  Again the list of filters would be user
extendable.  (Which is essentially what we have now, of course, but without
the pluggable filters.)

4) List of methods satisfying the current method filter (from this class or
this class and superclasses).  (Which is just what we have now).

Then the current CHB would be a special case of the 4-pane SB without the
class filter panel.  If you had the option to open/hide the class filter
pane then the CHB and SB would become one again.

Just a thought.  And I don't claim it'd be easy to do.

Oh, btw, in the above "ideal" 4-pane browser, or even in the present
browsers (at least as far as methods filters go), it would be quite nice if
when a method/class is selected all the filters that "answer true" for it
were shown in bold (or otherwise emphasised).  So, when I am viewing
#createSchematicWiring, the 'initializing' and 'events' category names would
stand out.  Again, just a thought, and easier to say than do...

> Blair

    -- chris

Chris Uppal wrote:

Remember - IBM *is* a hardware company. Considering the size of machine you
needs for things like WebSphere and VA, you can easily understand why I'm
switching to Dolphin ;-)

> > "Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
> > Krysten Nygaard
>
> What on earth was a Swede doing sober at such a time and date ?
>
> ;-)

Maybe *that's* what got him the Turing award!


--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
Krysten Nygaard

Chris,

Ok, as I pointed out in another message, I've also been experimenting with
the hierarchical class view within the SB. Actually, I quite like it, but
not as a replacement to the list. I think (as you also point out) one needs
both. The system browser has traditionally (in other STs of course) been the
place where newbies can explore the system. The alphabetically sorted list
of classes aids this exploration. The problem with a hierarchy (and this has
always been the case with the CHB) is that it requires knowledge of the
hierarchy to navigate through it successfully.

So let's settle on a tabbed pane that switches between list and hierarchy
views. Whether these are pluggable in the initial implementation we'll have
to see..

However, having got this all working in my system browser I've found that
populating my "partial tree list" with a large number of classes in the SB
is extremely slow (i.e. 15secs to expand and display the entire class
hierarchy on my 1.6Ghz m/c). Thinking that this is probably unusable :-) I
think some optimization may be called for. Before I do this, do you have a
working version of your component you can send me; assuming you don't mind
the code being subsumed into Dolphin?

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> A few reflections:
>
> > [...] However
> > we weren't quite happy with having lots of nodes in the tree that didn't
> > actually pass the "filter", but were necessary to maintain the
structure.
>
> Well, I don't think you can have it both ways -- either you display the
full
> structure (and so get full information, but at the cost of extra -- but
not
> extraneous -- nodes) or you don't.
>
> The greying out seems to work pretty well; as I've said, you (or anyone)
are
> welcome to try my  Project Browser if you'd like to get a hands-on feel
for
> a filtered hierarchy.
>
> Thinking about Ian's point (statement, claim, confession, whatever ;-)
that
> he finds that the new SB gives him  a "much smoother" programming
> experience, when I am finding quite the reverse.  I wonder if it's
dependent
> on the progamming style in use at the time.
>
> If the problem is such that the natural approach has a reasonably small
> number of more-or-less independent classes (all either subclassing Object,
> or some well-known class like Presenter) then the linear presentation may
be
> optimal.  If, otoh, the solution is one that makes use of lots of classes
> arranged such that their inheritance is central to their function (using a
> lot of polymorphism, for instance) then the linear approach doesn't work
at
> all, and the hierarchical presentation is pretty much a necessity.
>
> So it may depend on the problem domain (and the programmer too, I
suppose --
> but I don't think that Ian's style and my own are inherently all that
> different) whether either is even usable, let alone ideal.
>
> As it happens, just about everything I'm doing just now has lots of little
> classes, so I don't get on at all with the linear presentation.
Ironically,
> the exception is the Project Browser (which I've been sprucing up a
> little) -- it's main window is a subclass of the CHB so it's
inconveniently, as
> a tree or as a list according to user choice.  The greying out technique
> would be used where appropriate.  (Probably a tabbed pane too.)
>
> 3) Tabbed list of different kinds of method filter -- by category, by
> package, by instvar, by protocol.  Again the list of filters would be user
> extendable.  (Which is essentially what we have now, of course, but
without
> the pluggable filters.)
>
> 4) List of methods satisfying the current method filter (from this class
or if
> when a method/class is selected all the filters that "answer true" for it
> were shown in bold (or otherwise emphasised).  So, when I am viewing
> #createSchematicWiring, the 'initializing' and 'events' category names
would

Andy,

> So let's settle on a tabbed pane that switches between list and hierarchy
> views. Whether these are pluggable in the initial implementation we'll
have
> to see..

There's no need for that bit to be pluggable is there ?  Only the filters,
I'd have thought, wanted to be extensible (in whatever release).

> However, having got this all working in my system browser I've found that
> populating my "partial tree list" with a large number of classes in the SB
> is extremely slow (i.e. 15secs to expand and display the entire class
> hierarchy on my 1.6Ghz m/c). Thinking that this is probably unusable :-) I
> think some optimization may be called for. Before I do this, do you have a
> working version of your component you can send me; assuming you don't mind
> the code being subsumed into Dolphin?

Sent to you under separate cover.

I hit similar (but not as extreme -- oddly, 'cos this is only a 650Mz box)
performance problems and resorted to caching.

Please make use of anything you want, and welcome.

> Andy Bower

    -- chris