help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Improving VisualGST Menu


From: Gwenaël Casaccio
Subject: Re: [Help-smalltalk] Improving VisualGST Menu
Date: Tue, 2 Nov 2010 10:09:22 +0100

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 <address@hidden> wrote:
> 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
>>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]