[Help-smalltalk] visualgst plans

[Paolo Bonzini]

Hi Gwen,

1) I pushed my changes and rebased them on top of the save widget stuff.
It can be pulled. The main fixes are that Tools menu behavior is more
uniform across all browsers, and that many bugs in "Accept it" were
fixed.  I also finished my previous refactoring by moving more methods
from browsers to BrowserState, so that the Commands can rely on the
state more and more instead of asking the browsers.

There are still a couple of sore points in the class hierarchy, but I
think we're relying less and less on duck typing---which makes the
system easier to understand and enhance.

I'm thinking of dropping the webkit stuff since it's probably bitrotted
and not too used.  Is this fine for you?

2) I took a look at the state save widget. It looks great, it could
"feel" much better. There it makes sense to choose
between accept, cancel and close. In the future, instead of "accept" you
may even propose special choices such as declaring variables as
temporary or instance.

However, there is one serious problem: it makes the modal choice of
"what to do after clicking somewhere in the upper half of the browser"
modeless. It is great when you have a compile error, much better than
the "insert error as selection" you have in Squeak. I think the old
dialog should be preserved in case the state changed. In this case you
have to choose between accept/cancel/revisit (the third choice brings
back the old selection), but you have to do so modally. If you choose
accept and there is a compile error, the choice should be changed to
revisit, and the save widget should pop up.

Also, the save widget must work with all browsers. With my recent
changes I moved "accept it" to the GtkSourceCodeWidget, and this should
make it easier to refactor save widget stuff so that it works in the
debugger, inspector browser, SUnit browser, GtkLauncher, and regular
class browsers (sender/inspector should already be taken care of).

The compiler errors pane in GtkLauncher can then be removed, and no
Debuggers should pop up upon a compiler error.

Do you agree?

At the same time (actually, after everything above is sorted out since
this is a relatively trivial change and should be done in a separate
commit) we may want to rename accept/cancel/revisit to
accept/drop/cancel. What do you think?

3) I also filed these:

http://smalltalk.gnu.org/project/issue/508
http://smalltalk.gnu.org/project/issue/509

509 is totally unimportant. 508 is a bit more urgent, but less than
sorting out the save widget. The widget is a step in the right
direction and it's fine to have it in 3.2.1 (compiler errors were
quite broken, or at least less usable than Squeak/Pharo) but it is
not finished and that's the priority.

4) Least important of all, the redesign of the sender/inspector
browsers. I think it would be nice to have the symbols expandable in the
left pane, and the expansion will hold the senders/inspectors of those
symbols. I'm not sure if GtkTreeModel supports on the fly loading of
rows as soon as the parent is expanded. I think not, so don't rush on
this. It can definitely be done past 3.2.1, or not at all. I just
included it in this email because you mentioned on IRC that you wanted
to have different kinds of sidebars.

Paolo