[Sugar-devel] [PATCH sugar-toolkit-gtk3] sugar-activity: import and make independent of sugar-toolkit GTK versions

Simon Schampijer simon at schampijer.de
Mon Dec 19 12:53:30 EST 2011


On 13/12/11 21:32, Simon Schampijer wrote:
> On 13/12/11 16:47, Daniel Drake wrote:
>> As we move to adding support for a second UI toolkit (GTK+ 3.x),
>> the sugar-activity binary used by all activities must become
>> backend-toolkit-independent. It would be wasteful to have two backend
>> toolkits loaded in memory, and in the GTK2/GTK3 case, it is impossible
>> (importing both results in an instant crash).
>>
>> To achieve this, we split the existing sugar-toolkit
>> activity/main.py:main()
>> functionality into two parts, moving it into the sugar-activity binary
>> and
>> the Activity class as follows:
>> 1. All toolkit-specific stuff is moved into the Activity class (i.e.
>> everything that interacts with GTK)
>> 2. Everything that can be reasonably/easily moved into the Activity class
>> is also moved.
>> 3. What remains is the stuff that is inherently involved with the
>> construction of the Activity object, not related to UI toolkits. This
>> is moved into the sugar-activity binary.
>>
>> main.py is then removed from sugar-toolkit, and sugar-activity is moved
>> from sugar to sugar-toolkit-gtk3 in order to keep toolkit-related code
>> with the toolkit itself.

One thing I don't like with moving the 'sugar-activity' inside 
sugar-toolkit-gtk3 is that we make the sugar-toolkit-gtk3 dependent on 
the sugar-toolkit-gtk2 as we use modules from it:

import sugar
from sugar.activity import activityhandle
from sugar.bundle.activitybundle import ActivityBundle

Actually, even having it in the shell makes it only slightly better as 
we still have the hidden dependency of the gtk3 toolkit on the gtk2 
toolkit, for a gtk3 activity to start we still need the gtk2 toolkit. 
Hmmm... Maybe that is as well ok and we just need to clearly communicate 
that.

Regards,
    Simon



More information about the Sugar-devel mailing list