On Wed, Jul 1, 2009 at 11:44, Aleksey Lim<alsr...@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 Lim<alsr...@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 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). >> > >> > 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