[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] Improving VisualGST Menu
From: |
Paolo Bonzini |
Subject: |
Re: [Help-smalltalk] Improving VisualGST Menu |
Date: |
Sun, 31 Oct 2010 09:46:16 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.4 |
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