[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