system browser bugs

I prefer to use the system browser, but there are some things that make it
difficult to use at times:

*) If you add a new package and have a system browser open, the system
browser will deselect the item in the tree list at the top and select all
packages in the package list. If you then select a package and try to
uninstall it, you'll get an error. PackageSelector>>uninstall: is trying to
get the tree view's selection, but nothing is selected. I would prefer the
browser to not deselect my directory in the tree list.

*) When you initially open the system browser and select a package, it will
display a class definition for Object. You can modify this class definition
and create a new class (with Ctrl-S). However, if you create a new package,
it will no longer display the class definition of Object. Instead it
displays nothing. If you enter a new class definition, and hit Ctrl-S, the
class will not be created. The only way to create the class is to evaluate
the code.

*) If you select a method in a different package it disables the method
pane. Now, if you switch to a different package, select a class, and a
protocol, the method pane will still be disabled. You will need to first
select a method that can be edited. Of course, this can be difficult if
there is only one class in the package and it has no methods. I'm not sure
of all the conditions to get this to happen, but hopefully I've given enough
for you to reproduce it.

*) When I compile a class definition or method, it should go in the package
that I have selected. Currently, it goes in the default package. The default
package should only be used if there isn't a selected package.

*) When a method is in another package, it won't let you edit the method. I
would prefer the ability to edit the method and when accepting, it would ask
if the method should go in the original package or in the currently selected
package. The method pane should only be disabled when there isn't a class
selected.


John Brant

John

You wrote in message news:u63l9.26401$wH.2593@sccrnsc01...
> I prefer to use the system browser, but there are some things that make it
> difficult to use at times:
>

Thanks for the bug reports, and suggestions:

> *) If you add a new package and have a system browser open, the system
> browser will deselect the item in the tree list at the top and select all
> packages in the package list. If you then select a package and try to
> uninstall it, you'll get an error. PackageSelector>>uninstall: is trying
to
> get the tree view's selection, but nothing is selected. I would prefer the
> browser to not deselect my directory in the tree list.

I agree about the selection change - it would be preferable if it didn't do
that. The browser is doing the simplest thing possible when the set of
packages changes to reflect any possible changes in the package hierarcy,
which is to completely rebuild the tree. I'll record that as an enhancement
request if one doesn't already exist.

Regarding the bug it can be reproduced in 5.01 by causing selection to be
lost in the filter tree by right clicking over no-mans land below the last
item, and then attempting the uninstall. It seems that I spotted it and
fixed this in July, the change being in the PackageSelector>>uninstall:
method. The change being:
 <!  currentFolder := self filterPresenter selection.
 !>  currentFolder := self filterPresenter selectionOrNil.

>
> *) When you initially open the system browser and select a package, it
will
> display a class definition for Object. You can modify this class
definition
> and create a new class (with Ctrl-S). However, if you create a new
package,
> it will no longer display the class definition of Object. Instead it
> displays nothing. If you enter a new class definition, and hit Ctrl-S, the
> class will not be created. The only way to create the class is to evaluate
> the code.

Use the Class/New menu bar command, which is linked to the Add Class
refactoring in DPro, and which allows you to specify the package into which
a class should be created, defaulting to the package selection in the system
browser, or the package of the superclass in the class hierarchy browser.

>
> *) If you select a method in a different package it disables the method
> pane. Now, if you switch to a different package, select a class, and a
> protocol, the method pane will still be disabled. You will need to first
> select a method that can be edited. Of course, this can be difficult if
> there is only one class in the package and it has no methods. I'm not sure
> of all the conditions to get this to happen, but hopefully I've given
enough
> for you to reproduce it.

I haven't so far, but I think I have seen it myself at some point.

>
> *) When I compile a class definition or method, it should go in the
package
> that I have selected. Currently, it goes in the default package. The
default
> package should only be used if there isn't a selected package.

That is the way the "default package" was specified by those who wanted it,
although as it turned out I don't think it really turned out to be what they
wanted either. Its mainly intended as a way of setting up a default package
to receive the contents of chunk format files, which might be useful for
importing from other environments. Frankly it would be better if there was a
less "modal" way to do that, in which case I think the default package
feature should probably be removed altogether.

>
> *) When a method is in another package, it won't let you edit the method.
I
> would prefer the ability to edit the method and when accepting, it would
ask
> if the method should go in the original package or in the currently
selected
> package. The method pane should only be disabled when there isn't a class
> selected.

That is by design (for better or worse). To edit the method in the currently
selected package (i.e. changing its ownership), drag it across and drop it
over the package in the package list. It will then become enabled. Editing
it in its existing package requires either opening a new browser, or if the
method is not currently loose then you can quickly navigate to the package
of the defining class using the "Goto Definition" command on the class
context menu (there probably ought to be an equivalent on the method context
menu).

Regards

Blair

Blair McGlashan wrote:

Seehttp://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&as_qdr=m3&selm=3D4B7909.CF1530F8%40shoshana.com

where I documented two months ago a sequence of steps to reproduce the problem.


> ....  Editing
> it in its existing package requires either opening a new browser, or if the
> method is not currently loose then you can quickly navigate to the package
> of the defining class using the "Goto Definition" command on the class
> context menu (there probably ought to be an equivalent on the method context
> menu).

It sure would be nice if the "Goto Definition" command would cause the package
list to scroll such that the selected package becomes visible.


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

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
> Blair McGlashan wrote:
>
> > John Brant wrote:
> > > *) If you select a method in a different package it disables the
method
> > > pane. Now, if you switch to a different package, select a class, and a
> > > protocol, the method pane will still be disabled. You will need to
first
> > > select a method that can be edited. Of course, this can be difficult
if
> > > there is only one class in the package and it has no methods. I'm not
sure
> > > of all the conditions to get this to happen, but hopefully I've given
> > enough
> > > for you to reproduce it.
> >
> > I haven't so far, but I think I have seen it myself at some point.
>
>
Seehttp://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&as_qdr=m3&sel
m=3D4B7909.CF1530F8%40shoshana.com
>
> where I documented two months ago a sequence of steps to reproduce the
problem.

Thanks, I'll check that out.

> It sure would be nice if the "Goto Definition" command would cause the
package
> list to scroll such that the selected package becomes visible.

Try the attached. I'd be interested to know your (or anyone elses) opinions
on it - this causes the filter to sync as well, which I suppose might not be
what one would want if one were viewing at a higher level in the tree and
didn't want to lose that high level view. I reasoned, though, that one
wouldn't want to be doing a 'Goto Definition' unless that was the behaviour
one wanted. The change is made in a "generic" location where I believe it
belongs, but it may have other unwanted side effects that I haven't seen
yet. It doesn't cause any of our related SUnits to fail, but with UI stuff
there is no substitute for experience in use.

Regards

Blair
----------------------------

!PackagedClassSelector methodsFor!

resetForItem: aClass
 "Private - Try to ensure that the receiver is set to display aClass if
possible"

 | owningPackage |
 (owningPackage := aClass owningPackage) notNil
  ifTrue:
   [(self packagesPresenter)
    resetForItem: owningPackage;
    selections: (Array with: owningPackage)]! !
!PackagedClassSelector categoriesFor: #resetForItem:!event handling!private!
!

Blair McGlashan wrote:

Well the jury is still out on this change. <g> I can't quite decide if I like
the automatic "Goto Folder" when one does the "Goto Definition", or not. On the
one hand, the times I most remember getting ticked off at the package list not
making the selection visible after a "goto definition" was when I had to scroll
through it looking for the selection because I then wanted to "goto folder" on
it. On the other hand, I don't like losing the higher level view of packages if
that's where I'm at. One can't go higher in the tree while maintaining the
current package selections without a lot of work. Perhaps it would be good to
maintain the package selections when moving up the tree? On the gripping hand,
the automatic selection of all the packages is often a good thing. Perhaps I
digress too much...

Your change didn't address my specific problem directly. Granted, by going to
the folder, most times the package list becomes short enough that scrolling
isn't an issue. I guess it all depends on how one uses the tree structure -
depth vs. breadth and all. It did point out the "generic" location where I could
try my own changes. :-) I inserted #ensureSelectionVisible, and it now seems to
do what I want.

I think that I'll live with the following version for a while and see how I like
it. After a "goto definition" the package is visible, so that a second step of
"goto folder" is easy to do if that's what I want. But it  leaves the folder
selection alone, should that not be what I want. I'll try and see if I can be
aware of which is the case when I use "goto definition".

regards,
-Bill


!PackagedClassSelector methodsFor!

resetForItem: aClass
 "Private - Try to ensure that the receiver is set to display aClass if
possible"

 | owningPackage |
 (owningPackage := aClass owningPackage) notNil
  ifTrue:
   [(self packagesPresenter)
    "resetForItem: owningPackage;"
    selections: (Array with: owningPackage);
    ensureSelectionVisible]! !
!PackagedClassSelector categoriesFor: #resetForItem:!event handling!private! !

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