[Sugar-devel] [Sugar-Devel] Toolkit version in the activity info

Daniel Narvaez dwnarvaez at gmail.com
Fri Feb 14 08:23:43 EST 2014


It is a complex issue, let me try to summarize my understanding of it

* We support multiple toolkits and we need a good to find out which toolkit
each activity uses.
* IMO trying to figure that out by analyzing the code is not good. Too
complicated and too fragile.
* We have a decent way to detect the toolkit by looking at the exec line.
Unfortunately that doesn't works for gtk3 vs gtk2 because we (mistakenly)
didn't make multiple sugar-activity installable in parallel.
* Another possible way to handle it would be to have an explicit toolkit
property in activity.info. That would require to update either all gtk3 or
gtk2 activities though.

So, all in all I don't see a satisfactory solution to distinguish gtk2 and
gtk3. Given that gtk2 has been long deprecated I tend to think we should
just give up with that. Let's spend time porting activities instead :) For
the future looking at the exec field seems good enough. So if we ever
release a gtk4 toolkit we should have a sugar-activity-gtk4 script.

On 13 February 2014 17:15, Manuel Quiñones <manuq at laptop.org> wrote:

> 2014-01-31 23:14 GMT-03:00 Daniel Narvaez <dwnarvaez at gmail.com>:
> > On 1 February 2014 03:00, Sam Parkinson <sam.parkinson3 at gmail.com>
> wrote:
> >>
> >>
> >> Hi,
> >>
> >> Dnarvaez and I were discussing this on the irc; we really need to do
> >> distinction between the tool kit version in activity.info.
> >>
> >> This would be needed to for:
> >>
> >> view source
> >> because now changes to sugar-toolkit-gtk3 can break the gtk2 toolkit (!)
> >>
> >> Basically we were thinking to make a new thing: sugar-activity3 to
> launch
> >> gtk3 activities.
> >
> > It should probably just be a symlink.
> >>
> >> It would probably be the same at first, but in the future could be used
> to
> >> stop breakage to gtk2 activities.
> >
> >  I think it was a mistake to not make a sugar-activity3 when we ported.
> > Though I'm not sure we can undo that now. It would be an API breakage
> (gtk3
> > activities would stop to work unless they changed to sugar-activity3).
> >
> > If ever make another parallel installable gtk toolkit it should
> definately
> > be sugar-toolkit4 though :)
> >>
> >> So yeah, is this going to break everything? Could you think of a better
> >> way?
> >
> > It should not break much actually. Activities that have not switched to
> > sugar-activity3 will just not get the right sugar toolkit in view source.
> >
> > The main issue is probably that activities that change to sugar-activity3
> > won't run on old sugar versions. Sigh... wish we had done this when
> porting
> > really :/
> >
> > The alternative, as we discussed, is a new "toolkit" property in the
> info.
> > That should not break stuff, it's one more thing to remember for activity
> > authors though. Maybe we can have bundlebuilder warn about it.
>
> So, do we agree to have toolkit type and version in the activity.info?
> We have a pull request on this:
>
> https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/104
>
> I'm fine with this. I think we need two versions: minimum and maximum.
> This is the same activities.sugarlabs.org has.
>
> Also see Android manifest as reference:
> http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
>
> --
> .. manuq ..
>



-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140214/f7f82850/attachment.html>


More information about the Sugar-devel mailing list