Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
I recently looked over sugar-port source, and I found this http://people.sugarlabs.org/~alsroot/sugar-port/ It's equivalent to my patch, but is slightly less readable. 2009/7/1 Tomeu Vizoso to...@sugarlabs.org: On Wed, Jul 1, 2009 at 15:18, Lucian Branesculucian.brane...@gmail.com wrote: Sorry about that. I've attached another patch which follows the guidelines. I'm not sure I should be opening a ticket about this, though. I've had a chat with Walter last night and he said that since the toolbar will get a re-haul in 0.86, it's a chance to improve the API as well. If we really manage to implement that feature for 0.86 (the design is not agreed on as of yet), the API will have to be a separate addition because we'll need to keep both the old tabs-based toolbox and the new one as not all activities will be able to move to the new one at the same time. That said, your patch seems clean enough to be added now and the fact this API is going to get deprecated makes it easier to add API to it. Regards, Tomeu 2009/7/1 Tomeu Vizoso to...@sugarlabs.org: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). Thanks! Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
I didn't realise the docs didn't use a get url. Look for ActivityToolbox.get_bars in the activity module. 2009/7/4 Lucian Branescu lucian.brane...@gmail.com: I recently looked over sugar-port source, and I found this http://people.sugarlabs.org/~alsroot/sugar-port/ It's equivalent to my patch, but is slightly less readable. 2009/7/1 Tomeu Vizoso to...@sugarlabs.org: On Wed, Jul 1, 2009 at 15:18, Lucian Branesculucian.brane...@gmail.com wrote: Sorry about that. I've attached another patch which follows the guidelines. I'm not sure I should be opening a ticket about this, though. I've had a chat with Walter last night and he said that since the toolbar will get a re-haul in 0.86, it's a chance to improve the API as well. If we really manage to implement that feature for 0.86 (the design is not agreed on as of yet), the API will have to be a separate addition because we'll need to keep both the old tabs-based toolbox and the new one as not all activities will be able to move to the new one at the same time. That said, your patch seems clean enough to be added now and the fact this API is going to get deprecated makes it easier to add API to it. Regards, Tomeu 2009/7/1 Tomeu Vizoso to...@sugarlabs.org: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). Thanks! Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). Thanks! Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). In my case(writing activities for 0.82+) it doesn't make any sense to have this patch in sugar-toolkit because its 0.86 feature. Moreover I did similar thing in sugar-port(and use sugar-port wrapper instead of using sugar-toolkit directly) http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 01, 2009 at 11:38:51AM +0200, Tomeu Vizoso wrote: On Wed, Jul 1, 2009 at 11:31, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). In my case(writing activities for 0.82+) it doesn't make any sense to have this patch in sugar-toolkit because its 0.86 feature. Moreover I did similar thing in sugar-port(and use sugar-port wrapper instead of using sugar-toolkit directly) http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 How that line of code relates to the toolbar patch? It was just an example, the idea is - adding new features to sugar-toolkit API leads activity developers to write 0.86+ code but having these features in libraries like sugar-port let them write 0.82+ code. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 1, 2009 at 11:44, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 11:38:51AM +0200, Tomeu Vizoso wrote: On Wed, Jul 1, 2009 at 11:31, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). In my case(writing activities for 0.82+) it doesn't make any sense to have this patch in sugar-toolkit because its 0.86 feature. Moreover I did similar thing in sugar-port(and use sugar-port wrapper instead of using sugar-toolkit directly) http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 How that line of code relates to the toolbar patch? It was just an example, the idea is - adding new features to sugar-toolkit API leads activity developers to write 0.86+ code but having these features in libraries like sugar-port let them write 0.82+ code. Sure, I have no problem with activity developers using sugar-port or whatever they find appropriate. We need to add new features to sugar-toolkit for the activity authors that need new stuff. If sugar-toolkit is not going to keep being improved, then people would be better off not using sugar-toolkit and just using sugar-port or whatever. If they use sugar-port and it is installed at the system-level, then we have something that is exactly the same as sugar-toolkit. If it is copy-pasted inside every activity, then sugar core developers won't be able to help activity authors debug issues in their activities and the first step to develop sugar activities will be a bit higher. I would say it's up to activity authors, though distro packagers might be also bothered to have to package duplicated code. But I think that activities shouldn't be packaged by distros anyway. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 1, 2009 at 15:18, Lucian Branesculucian.brane...@gmail.com wrote: Sorry about that. I've attached another patch which follows the guidelines. I'm not sure I should be opening a ticket about this, though. I've had a chat with Walter last night and he said that since the toolbar will get a re-haul in 0.86, it's a chance to improve the API as well. If we really manage to implement that feature for 0.86 (the design is not agreed on as of yet), the API will have to be a separate addition because we'll need to keep both the old tabs-based toolbox and the new one as not all activities will be able to move to the new one at the same time. That said, your patch seems clean enough to be added now and the fact this API is going to get deprecated makes it easier to add API to it. Regards, Tomeu 2009/7/1 Tomeu Vizoso to...@sugarlabs.org: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). Thanks! Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
I have some workarounds in my Browse, it works fine without that patch on 0.84 I haven't tried it on 0.82 yet, but AFAIK Browse 108 doesn't work in 0.82. None of my changes should prevent it from running on 0.82 though, so I should be able to backport them. It's just not something I've tackled yet. 2009/6/30 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Lucian Branescu wrote: I have attached a patch to toolbox.py, in the sugar.graphics package. What is your plan for backwards compatibility? Do you intend for your SSB-enabled Browse to run on 0.84 or 0.82? --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
I have some workarounds in my Browse, it works fine without that patch on 0.84 I haven't tried it on 0.82 yet, but AFAIK Browse 108 doesn't work in 0.82. None of my changes should prevent it from running on 0.82 though, so I should be able to backport them. It's just not something I've tackled yet. 2009/6/30 Benjamin M. Schwartz bmsch...@fas.harvard.edu: Lucian Branescu wrote: I have attached a patch to toolbox.py, in the sugar.graphics package. What is your plan for backwards compatibility? Do you intend for your SSB-enabled Browse to run on 0.84 or 0.82? --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
