Commit from Sugar Labs: Translation System by user samybt.: 395 of 395 messages translated (0 fuzzy).
Commit from Sugar Labs: Translation System by user cjl.: 95 of 395 messages translated (5 fuzzy).
Merge branch 'master' of github.com:sugarlabs/sugar
Merge branch 'master' of github.com:sugarlabs/sugar
Use the new toolkit unit test discover helper
Commit from Sugar Labs: Translation System by user cjl.: 398 of 398 messages translated (0 fuzzy).
Commit from Sugar Labs: Translation System by user cjl.: 398 of 398 messages translated (0 fuzzy).
Commit from Sugar Labs: Translation System by user cjl.: 398 of 398 messages translated (0 fuzzy).
Merge branch 'master' of github.com:sugarlabs/sugar
Commit from Sugar Labs: Translation System by user samybt.: 398 of 398 messages translated (0 fuzzy).
Bundle registry: Cleanup/clarify bundle installation

Management of bundle installs/upgrades was a mess, this attempts to
clean it up and sort it out.

It was not clear under which circumstances a bundle should be installed
via the bundle object vs via the bundle registry. The logical answer here
is that it should be done by the registry, so document why that is the case.

In bundleregistry, upgrade() seemed like it should be used for bundle
updates, but actually install() duplicated some of that logic in a slightly
different way. Touch up the upgrade logic in install(), remove upgrade(),
and add some documentation to make the situation clear.

The install() API differed between JournalEntryBundle, ActivityBundle and
ContentBundle. Eliminate the differences. JEB uid's are now stored at
initialization time, and the Bundle classes themselves choose the install
path (this does not vary when activities are installed this way).

The journal had two codepaths that dealt with activity installation/upgrade
(on arrival of the bundle in the datastore, and on resume)); unite them into
one and update for the above changes.
bundleregistry: Fix conflict between file monitoring and its own operations (#3707)

When an activity is installed via bundleregistry, it is effectively
registered twice: once by bundleregistry after installing it, and again
when the file operations monitor picked up the event.

This lead to error messages in the logs and occasional duplication
of activity icons in the home view.

Refactor the code slightly so that it is resilient and accepting that
some activities may try to be registered twice. To avoid the duplication
of icons, be more careful to only emit the bundle-added signal when we
really add the bundle.

Also clean up the installation of MIME types. The ActivityBundle class
does this, so there is no need for bundleregistry to do so.
Store content bundles in bundle registry

Previously, only activity bundles were maintained in the bundle registry.
Extend this to cover all kinds of "trackable" bundles, which in reality
just means the addition of content bundles.

This is needed in order to clean up the code and bundle API (as has happened
here) and to allow content bundle updates through the updater control
panel.
Move activity update code to jarabe.model

In preparation for implementing automatic/background activity updates,
move the code from an extension-specific model into jarabe.

The main update code is now in jarabe.model.update and the downloader
has been made generic and moved to jarabe.util.downloader. It now
downloads files into the temporary 'data' directory which is cleaned up
on every Sugar launch, avoiding leaving stale files around in failure
cases.
Don't initialise GTK+/dbus thread support

These calls allow GTK+ and dbus to be used from other threads.
Sugar doesn't currently create any threads, so these calls aren't
needed.

This is useful for followup work where some main loop recursion
results in a function that is sometimes called with the GDK threads lock
held, and sometimes without it held. By disabling this threading support,
this lock (and the surrounding headache) goes away.

By not activating the threading lock, we should also have a minor
performance increase.

Threads can still be used if desired, but all GTK+ calls should be made
from the main thread. These functions have actually been deprecated
in GTK+ 3.6 as the developers have determined that "draw from one thread"
is the way to go.

The GLib.threads_init() call is still needed, as we do have users
that work with threads, so the GIL must be released accordingly. However it
can be removed once pygobject-3.10 is a requirement:
https://bugzilla.gnome.org/show_bug.cgi?id=686914
bundleregistry: Add asynchronous install capabilities

In preparation for automatic activity updates, add asynchronous install
capabilities to the bundleregistry.

The synchronous install implementation has been removed and is now a user
of the async API that waits for completion before returning.

In order to avoid painful corner cases, the bundleregistry maintains
a queue of bundles to install, and installs them one by one. Install is
done in another thread to not block the main one.

As the install thread requires brief access to the list of bundles in the
bundle registry, all accesses to bundleregistry._bundles are now serialized
with a lock.
updater: asynchronously update bundles

This means that we unblock the main thread, a crucial step
towards offering automatic background activity updates.
Automatic activity updates

A new auto_update_frequency gconf key (default 0, disabled) enables
automatic activity update at an interval specified in days.

Sugar checks if this threshold has been met 10 minutes after launch,
and then every hour.

Activity upgrades are done completely in the background, but if the
user opens the updater control panel section while an update is in
progress, the background update is effectively brought into the
foreground and the user can monitor its progress.

This required a bit of view/model rework so that the view can be regarded
as a client that can attach at any point during the update process.
Implement urgent background activity updates

Dropping an empty .sugar-update flag file in the home directory will
now trigger an automatic background activity update ran as soon as
network connectivity is available.

This is designed for use after a system upgrade. Upon major Sugar and OS
upgrades, user activities will often need to be updated to new APIs, etc.
The system upgrade tool should put this file in place, which will then
trigger Sugar to try hard to update the user's activities.

This replaces the previous use of the .sugar-update functionality,
which was to show a message advising activity update, which turned out
to be somewhat ineffective in the field.
Activity updater: move activity check logic into backend

Right now, the activity updater assumes that the backend requires one
query per installed bundle. That won't be true for the OLPC microformat
updater.

Move the query-by-query checking logic into the ASLO backend, turning
it into a class at the same time, in order to ease state tracking.