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

[Manuel Quiñones]

2014-01-31 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 :/

Yeah, is a shame we didn't thought about this.  Maybe because we
supposed that the move from gtk2 to gtk3 was transitory.

> 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.
>
>
> More ideas welcome!

For the View Source issue, the activities py files can be inspected.
If they contain gtk3 code, then show toolkit3.  Else, show the old
toolkit.  For example: grep -r --include="*py" "from gi.repository".

Not the cleanest option, but works if this is the only issue
identifying the proper toolkit for an activity.

-- 
.. manuq ..