[Help-smalltalk] visualgst

[Paolo Bonzini]

All,

I spent a pleasant afternoon refactoring and fixing bugs in VisualGST. 
Diffstat follows:

 73 files changed, 765 insertions(+), 724 deletions(-)

Looks pretty brutal. :-)

Most important changes:

- Fixed recategorization of classes

- Fixed add category.  Now it is not anymore an undoable command, since 
it's enough to just select another class to effectively undo the 
command.  This can be changed again later, when DeleteCategory is 
implemented (but how?)

- Removed UndoableCommand class.  The only interesting method could be 
moved to UndoCommand.

- Fixed various backtraces on "nothing is selected".  Commands now can 
refuse to execute, and there are abstract classes ClassCommand, 
MethodCommand etc. that refuse to execute if there is no selected class, 
method, etc.  Then, things such as FileoutClassCommand become subclasses 
of ClassCommand.

- Related to this, all commands now take a browser widget as their 
target.  You really should not pass classes, namespaces etc. to the 
commands, as this is the task of the UndoCommands instead.  This was 
necessary for the implementation of ClassCommand etc.

Anyway, let me say it again.  Commands a) should always decide what to 
do _only based on the selection in the GUI_, b) are immutable, c) are 
responsible for checking the validity of the state.   (I think that's 
already the case for all commands, but didn't really check).

Why?  Because the plan here is to create commands once and for all at 
browser creation time, and make them more integrated so that they can be 
connected to the enabling/disabling/showing/hiding of menu item.

Instead, UndoCommands should always decide what to do only based on 
their contents.  They're also immutable and responsible for checking the 
validity of the state, but the similarities end here.  If later there is 
a need, it is possible to change UndoCommand to UndoAction and add an 
abstract Action class for repeatable but non-undoable actions.  I was 
almost going to do this today, then decided that maybe we AGNI.

In fact, you could see UndoCommands as an instance of the Command 
pattern, while Commands mediate between the view (the GTK+ objects) and 
the controller (the GtkConcreteWidget).  Kudos to Gwen for the design. 
It was not (and still is not) totally fleshed out, but it's really 
waiting to come out beatifully.

- Also related to this, I completely redid the implementation of 
doit/printit/etc.  These now have their own Commands too.  The browser 
widget has control on the target object and asks the text widget to 
doit/printit/etc. with the given object.  The typical implementation is

    targetObject [
         ^something
    ]

    doIt: anObject [
         someTextWidget doIt: anObject
    ]

    doIt [
        DoItCommand on: self
    ]

This was necessary to fix DoIt and friends in debuggers and in inspector 
browsers.  I haven't tested it in the SUnit browser, so doit etc. may be 
broken there.  Despite the pleasure of the experience I was quite tired, 
so I decided to stop.  Doits in the debugger are much more important.

- I renamed the VisualGST class to GtkLauncher, since it conflicted with 
the namespace name.  Declaring the class with the same name as a 
namespace should really be forbidden.

- On top of this there are a few small "feel" improvements such as 
providing default buttons in the "Add" dialogs.


I already pushed it to the gst repo and to my visualgst fork on github. 
 Please test it and find bugs.

I don't think I'll have time for more work in fixing the Debian hangs, 
so I'll try to publish 3.2.1 in a week or two.  It will already have 
been almost two months since the release.  I don't have plans for 
opening the development of 3.3 yet, we need some calm.

Gwen, please merge master and stable.  Thanks!

Paolo