On Wed, Jul 1, 2009 at 15:18, Lucian Branescu<lucian.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 Branescu<lucian.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
