Re: [Help-smalltalk] Improving VisualGST Menu

[Gwenaël Casaccio]

On Sun, Oct 31, 2010 at 9:46 AM, Paolo Bonzini <address@hidden> 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
>