visualgst

>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
>
>_______________________________________________
>help-smalltalk mailing list
>[hidden email]
>http://lists.gnu.org/mailman/listinfo/help-smalltalk

> 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
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk