That's awesome Paolo, thanks! I'll give it a try and report bugs ASAP :) Cheers, Nico
Le samedi 12 juin 2010 à 19:45 +0200, Paolo Bonzini a écrit : > 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/help-smalltalk
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
