There is this pattern in Gtk*Widget classes aGtkClassWidget hasSelection ifFalse: [ ^ ... ]. a simple clean up: aGtkClassWidget ifNoSelection: [ ^ ... ].
Another proposal, with the refactorings we could - not now but in a long term - thing of a GTK independant version of VisualGST and why not use Iliad, or a Qt binding, ... Another proposal I don't know if you've looked at Gaucho, I think we could reuse all the widgets (namespace, classes, ...) and have that kind of behavior and why not plug clutter to have zoom in/zoom out :D, I see it as a new tool inside a tab (Gaucho paper : http://www.ics.uci.edu/~tproenca/icse2010/flexitools/papers/4a.pdf) These "porposals" are just two interesting exiting directions for VisualGST after the refactorings . On Tue, Nov 2, 2010 at 9:52 AM, Gwenaël Casaccio <[email protected]> wrote: > 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
