When an activity is launched, an import should first search the activity
bundle source rather than /usr/bin
Fixes the need to change activity sources every time a system package
conflicts with an import.
May impact any activity that relies on a system package being in search
path before the bundle source. Forty activities were tested, and none
relied on this.
The issue was caused by importing from activityfactory which caused GObject to be imported. This conflicts with GTK2. (Reported by James Cameron)
The idea is that we should create the sugar profile's activity root if it doesn't exist yet, when running outside Sugar.
- Handle lack of GSettings gracefully.
- Still requires sugar-datastore.
- Supports avoiding X11 docks/panels.
- Provides icons for Activity windows.
Try it outside Sugar. Go to an Activity directory and run 'sugar-activity'.
Tested it with Terminal, Finance, Write, Browse, Memorize under XFCE4.
Tested in Gnome under OLPC-OS.
Also works from Sugar Terminal Activity.
Does not affect regular Sugar operation.
This is patch v.2 -
Addresses most concerns:
- Removed commented code, sorry.
- Changed code to use profile.get_nickname and get_color where possible.
Couldn't the launcher just pass this info?
Maybe the launcher could set the activity root as well?
- It is intended to be usable from the command line also.
Should put sugar version in the environment
- It is intended to work even without Sugar Shell installed.
Why don't we always set the icon?
- On XO it might use some memory. I was concerned to degrade
performance.
Also, imports should be at the top of the file?
- Also a concern about performance on XO.
This way it is only loaded in this use case.
Maybe it is insignificant -moved as requested.
It would be nice if the changes to the POT for sugar-toolkit-gtk3
could be incorporated in this pull request, please.
- There were no changes to POT files as part of this patch. Maybe
it is worth translating low level command line tools, not sure.
Suggest packaged activities might also provide .desktop files.
- Intriguing but not sure within scope of this patch. You mean generate
a .desktop file automatically as an option? Sounds nice!
Suggest sugar-activity might also accept path to unpacked bundle.
- Implemented!
This problem only happen in activities configured with the option -s
in the activity.info "exec" field, and the objective is use a single process,
even when starting more than one instance. If the process do not reply,
start a new process, instead of show a error.
Signed-off-by: Gonzalo Odiard <godiard@sugarlabs.org>
If a env variable SUGAR_USE_WEBKIT1 exists,
uses a different module to start the activity using a local webserver,
borrowed from wikipedia activity.
When use webkit1 the web inspector is not enabled, because do not work.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
This drops a lot of code at the same time. The code in
__init__ was:
* Using a SUGAR_PREFIX environment variable that is not
defined anywhere
* Hardcoding prefix to /usr
* Setting up the sugar-base domain which doesn't exist anymore
The i18n module code was overcomplex because it was thought
for language packs which we don't support anymore, it was
not handling correctly locales with a country prefix, it
was hard coding the python prefix and it was not sorting
the directories as it intended too anyway.
The logic is very simple now. Use the locale directory in
the same prefix sugar-toolkit-gtk3 was installed, unless
SUGAR_LOCALEDIR is defined (for self contained bundles).
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>
