Re: [Help-smalltalk] Improving VisualGST Menu

[Paolo Bonzini]

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.

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.

> 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.

Paolo