[Sugar-devel] [API proposal] toolbox.get_toolbars()

[Tomeu Vizoso]

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