On Sun, Oct 31, 2010 at 9:46 AM, Paolo Bonzini <[email protected]> wrote: > On 10/31/2010 09:16 AM, Gwenaël Casaccio wrote: >> >> Ok I've made a branch where menu are refactored (done for >> NamespaceWidget and ClassWidget). > > Thanks for starting this! However, I don't understand why you made a > separate hierarchy. Right now you're not adding much benefit, the Command > objects are still not persistent. So, you don't have a real command pattern > where some time passes between creation and invocation of the Command. >
We've right (in fact I began the refactoring at 5 in the morning I was a bit tired :D), and I am merging everything. In the train this morning I've added accel supports in the commands : each tools has a path: GtkLaunch>>accelPath ^ '<VisualGST>' and we use the command class name to generate the full path name for example '<VisualGST>/OpenBrowserCommand' It seems fine for me > If you add your Menu class functionality to the Command objects, you will > have access to a lot of useful stuff, not only of course #execute and > #browser but also you can for example use the #precondition to > enable/disable menu items. Also you can store the Command objects in the > MenuBuilder and the GtkMenuItem in the Command, so that we can have a link > between the GtkMenu and the Command. In the future the Command might also > be able to create the toolbar item... > > As an appetizer, I pushed a patch to my master branch that renames Command > class>>#on: to Command class>>#executeOn:. In the long term I hope this > method dies. :) > >> The first point is really important now we have nothing for configuring >> VisualGST (the font, the color of the editor, behavior of the editor, ...) >> So we should express a set of preferences save/load them on a file (may be >> improve objectdumper design to serialize objects as ini/xml files) and >> build >> automatically the dialog box. > > This would be nice to have. > > For Git integration I think it can really be simple. It would start from > what you have in "git citool" and reimplement it in VisualGST. > Yep that will be cool >> The design is important and we should polish it but step by step and >> not breaking everything (I've made the experience and thus try to >> learn). > > I agree. I'm really sad I had to "break everything" for my incomplete work > which I still have to finish. Maybe during the sprint... Let's try to make > simple changes while it is pending (make small commits and avoid gratuitous > complications such as renaming instance variables). > >> (I've spend lot of hours to improve and polish it, really) we should >> work incrementally and step by step without breaking all the tools >> when we do a refactoring. Working on this software is a really nice >> experience and I'm trying to do a good job ;) > > I agree. > >> If you *really* want to help me try to improve/finish the packagebuilder >> tool, >> the preference framework, or ctrl+s that serialize automatically the >> files. > > This is a bit tricky because it would help only for files initially filed > out from VisualGST itself. Also it has the problem of preserving any top > comments like the ones in *.st files. It could reuse some of the code in > gst-convert. > For the header you could do like a lot of IDE a allow the user to choose the header: we could encode the licences (Mit, BSD, GPL, ...) or anything else ... > Paolo > _______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
