When writing Python apps that will use asynchronous DBus calls and
signals, python-dbus must be initialised with the appropriate main
loop.
sugar currently does this by importing the datastore module from
sugar-toolkit-gtk3, and the datastore module uses the deprecated
and confusing dbus.glib module (which automatically and non-obviously
sets the default GLib main context as the DBus mainloop).
Eliminate the dbus.glib usage from sugar-toolkit-gtk3 as part
of the effort to make sugar initialised the DBus mainloop in a
more explicit and non-deprecated fashion.
If the default locale is not set (see SL #4450 for a use case), get_locale_path
does now return None so that the sugar-activity script can handle that case
cleanly.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Reviewed-by: Daniel Drake <dsd@laptop.org>
As spoted by Daniel Narvaez in [1], pygi does not set the default encoding
anymore as the old GTK+ did. This change does break activities ported
to GTK+3.
The change in GTK+ has been discussed upstream here [2].
A better solution will be implemented when we port to Python 3,
when we will be able to use real unicode strings.
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
[1] http://lists.sugarlabs.org/archive/sugar-devel/2012-August/038993.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=681915
Must be done early, some activities set translations globally. Remove
the support for the langpackdir.
Signed-off-by: Simon Schampijer <simon@laptop.org>
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.
With this work done, the one remaining question is how to invoke the main
loop. An optional run_main_loop() method is added to the activity class,
for GTK2 this will run the GTK2 main loop, for GTK3 the GTK3 main loop will
be run, etc.
Signed-off-by: Daniel Drake <dsd@laptop.org>
the factory service from the public API. The Exec field
will now launch an activity instance.
Add a -s argument to sugar-activity to enable the single
process mode for activities that really need it.
