The design calls for two different startup animations, in the GDM
and in the normal session case.
In both cases, we implement fading from the previous situation
by acquiring the root background pixmap and turning it into a TFP
texture, which is then animated and blended by Clutter as normal.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
The background of the root window is accessible as the _XROOTPMAP_ID
property on the root window. Given that the root window is always
fully covered by the Composite Overlay Window, we use that as temporary
storage while the COW is not mapped, that is, before the GDM greeter
is started and between killing the greeter and starting GDM from the
session.
https://bugzilla.gnome.org/show_bug.cgi?id=682429
MetaBackgroundActor can now be constructed as a standard GObject, and
accepts a GnomeBG settings object, which we retrieve from the default
one to share textures.
https://bugzilla.gnome.org/show_bug.cgi?id=688210
It doesn't make sense to animate blindly a MetaBackgroundActor, given that
it shows the content of _XROOTPMAP_ID, so if gnome-settings-daemon is fast
we're animating the configured background, not the plymouth screen. And anyway
it would be animated on top of the standard MetaBackgroundActor...
It makes even less sense now that mutter renders the background on its own
(and blocks the first paint cycle until the background image is ready)
We need to do something better here, but for now, remove this.
https://bugzilla.gnome.org/show_bug.cgi?id=688210
Environment variables should be checked for zero length,
instead of non-zero. This prevented the script to run
correctly in a jhbuild shell for example.
https://bugzilla.gnome.org/show_bug.cgi?id=693031
Clutter translates keyboard state internally, and clears the lock bits
from modifier state, so translating again results in the wrong keysym.
Given that Clutter already gives us a fine keysym, we don't need this.
https://bugzilla.gnome.org/show_bug.cgi?id=692586
Now that we have an explicit active-but-not-locked state, we should
use different signals to notify changes. lock-status-changed is
renamed to active-changed, and a new locked-changed is introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=693007
As theme nodes keep a cache of matched properties, we need to make
sure to update it when the list of stylesheets changes. In particular
this fixes a regression from commit dc2ec0a8f9, which caused
extensions with stylesheets to crash the shell when re-enabled (for
instances when coming back from the lock screen).
https://bugzilla.gnome.org/show_bug.cgi?id=692994
StThemeNodes cache matched properties from stylesheets, so when the
list of custom stylesheets changes, the node may miss better matches
(when a stylesheet was added) or have pointers to invalid memory in
the list (when a stylesheet was removed).
In order to allow theme nodes to listen for stylesheet changes, add
an appropriate signal to StTheme.
https://bugzilla.gnome.org/show_bug.cgi?id=692994
While we handle the case where ibus_bus_get_global_engine() returns
NULL, this case actually generates an exception we have to catch to
avoid some (harmless) console spam.
https://bugzilla.gnome.org/show_bug.cgi?id=692995
In time span between idle and lock the shield should behave like autologin,
but should prevent accidental reactivation (for example when using a touch
screen) by showing the curtain.
https://bugzilla.gnome.org/show_bug.cgi?id=692560
gnome-settings-daemon wants to use ActiveChanged to drive screen
blanking policies.
I also added two big comments that should cover all cases, to clear
up what's happening when the idle timers fire.
https://bugzilla.gnome.org/show_bug.cgi?id=691964
We must remove music notifications before we're destroyed, otherwise
they get destroyed with us.
Also, integrate a review comment I previously forgot.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Some notifications, despite being emitted by shell code, should appear
to be from application or "separable" system components. Do that by
associating them with a notification-daemon policy.
Note that for this to look really good, empathy should rename itself
to Chat.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
The designs says that only music notifications should be shown in full
in the screenshield, the others should be either shown as a summary or
with very light details.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Allow message tray sources to provide a NotificationPolicy object,
that will configure how and if the source is displayed. For notification
daemon sources, this object is hooked to GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Use the new Hash.Map class, and store signal connections along with
the source and summaryItem. This allows to remove sources without destroying
them.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
A simple implementation of the ES6 Map proposal, internally
done as a hash table, using System.addressOf() to support keys that
are arbitrary objects.
Should help replacing linear searches in various places around the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
syncSectionTitle looks at device list for the section, to understand if
the section should be visible or not, so obviously it needs to see the
new device.
I wonder when this broke.
https://bugzilla.gnome.org/show_bug.cgi?id=692749
During the box pointer animation, other events can trigger an updateState,
losing the information that the summary is hiding and thus never disconnecting
the signals. Then, this stale connections can cause stacktraces, as they
fire when summaryBoxPointerItem is null.
https://bugzilla.gnome.org/show_bug.cgi?id=692693
Hiding notificationWidget with a telepathy notification causes
unfocused to be emitted, which causes a reentrant updateState.
If another notification is queued, it is shown before the old
one is cleared.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
The two classes have been gaining each other's functionality for a little
while, adding the new code wherever it was more convenient. Rather than
have a clear delineation between "This Manages Shell Chrome" and "This
Manages Shell Layout", I think it's better off if we just accept that
the responsibilities are pretty much the same.
https://bugzilla.gnome.org/show_bug.cgi?id=692677
