Improving VisualGST Menu
Locked
 
|
Hi,
With Gwen and Paolo we discuss on IRC on how to make a menu aware of model change. For example if we want to disable some menu or to have a check box on it. Since I can't remember what could go wrong with some solution I want to ask the ML. Possible solutions are: 1) use Annoucement 2) make Command behave like a controller for menu item. 3) Other solution For each there is some advantage and disadvantage. I will let Paolo and Gwen express themselves on it. In Cocoa they use the KVO pattern. I don't know how it work internally but maybe we could apply the same principle. Thanks for your help Mth __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
On 10/29/2010 07:50 PM, Mathieu Suen wrote:
> 1) use Annoucement > 2) make Command behave like a controller for menu item. > 3) Other solution > > For each there is some advantage and disadvantage. I will let Paolo > and Gwen express themselves on it. Announcements would be an implementation detail. If you add more functionality to the menus (as well as pluggable menus/toolbars), you need anyway to represent them with an object rather than use directly the GtkMenuItem. So (2) is a prerequisite anyway IMO. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
Ok I've made a branch where menu are refactored (done for
NamespaceWidget and ClassWidget). Mathieu if you want to do something useful for VisualGST: - Framework for preferences - debugger - ChangeSet - Git integration - work in team :D Other ideas a way to file out all the time when you do a ctrl+s, package management within VisualGSt with a tool like we have in linux distro (list of repositories/list of installed packages/...) 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. if you have another ideas I'm welcome and open. 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). But we shouldn't be only focus on design we should work on parallel to make progress on the other points to add new features. We are a small community and as the main developer (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 ;) 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. Gwen On Fri, Oct 29, 2010 at 7:53 PM, Paolo Bonzini <[hidden email]> wrote: > On 10/29/2010 07:50 PM, Mathieu Suen wrote: >> >> 1) use Annoucement >> 2) make Command behave like a controller for menu item. >> 3) Other solution >> >> For each there is some advantage and disadvantage. I will let Paolo >> and Gwen express themselves on it. > > Announcements would be an implementation detail. If you add more > functionality to the menus (as well as pluggable menus/toolbars), you need > anyway to represent them with an object rather than use directly the > GtkMenuItem. So (2) is a prerequisite anyway IMO. > > Paolo > > _______________________________________________ > help-smalltalk mailing list > [hidden email] > http://lists.gnu.org/mailman/listinfo/help-smalltalk > _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
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 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
On Sun, Oct 31, 2010 at 9:46 AM, Paolo Bonzini <[hidden email]> 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 [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
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 <[hidden email]> wrote: > On Sun, Oct 31, 2010 at 9:46 AM, Paolo Bonzini <[hidden email]> 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 [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
In reply to this post by MrGwen
On 11/02/2010 09:52 AM, Gwenaël Casaccio wrote:
>> 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 ... Copyright and license information can be different for each file. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
Le mardi 02 novembre 2010 à 11:11 +0100, Paolo Bonzini a écrit :
> On 11/02/2010 09:52 AM, Gwenaël Casaccio wrote: > >> 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 ... > > Copyright and license information can be different for each file. As I understand it, VisualGST will fileout 1 class per file, so we can be pretty sure than loading a package and doing a fileout will change the structure of the files. So, does it make sense to try to keep headers like they are right now? Cheers, Nico _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
On 11/02/2010 05:13 PM, Nicolas Petton wrote:
> Le mardi 02 novembre 2010 à 11:11 +0100, Paolo Bonzini a écrit : >> On 11/02/2010 09:52 AM, Gwenaël Casaccio wrote: >>>> 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 ... >> >> Copyright and license information can be different for each file. > > As I understand it, VisualGST will fileout 1 class per file, so we can > be pretty sure than loading a package and doing a fileout will change > the structure of the files. > > So, does it make sense to try to keep headers like they are right now? I'm all fine with changing the structure of the git tree according to what VisualGST prefers (in due time). However the copyright header shall remain, because the GPL suggests that: To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. and actually mandates that when you're distributing a modified version of another program: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. (which is actually taken care of by a copyright notice, too). Still, if you want to check out method modifications to a file, you can do that without changing the structure of the file. Reading the file, and writing it out, in gst-convert style (but with the new method in place and without reformatting) will provide exactly this. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
«
Return to Gnu
|
1 view|%1 views
| Free forum by Nabble | Edit this page |