This seems to cause more harm than good. It puzzles users looking at
the shortcuts list in g-c-c and it prevents otherwise valid shortcuts
like Shift+Hangul from working.
https://bugzilla.gnome.org/show_bug.cgi?id=695823
Currently we simply set the gsettings key when activating an input
source. This obviously introduces a time window, between the event that
activates the switch and when the switch is complete, under which key
events are being delivered to applications and interpreted according
to the previous input source.
The patches in bug 696996 introduce a DBus API in g-s-d that allows us
to know when an input source if effectively active. Using that and
freezing keyboard events in the X server until we hear back from g-s-d
we can ensure that events won't be misinterpreted after an input
source switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697007
It turns out that we never destroyed modal dialogs when closing
them, causing them to still linger in the scene graph even when
there were no references to them in the JS. The one case where
we don't want to destroy modal dialogs after being closed is
endSessionDialog, so provide a parameter that allows classes
to override this behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=697295
We chain up on _finish() to drop the grab and destroy the switcher
popup but we should activate the target window first because dropping
the grab results in the previously focused windows getting a focus in
event immediately followed by the focus out event from the target
window activation which we can easily avoid.
https://bugzilla.gnome.org/show_bug.cgi?id=696259
This ensures that when we have windows that are already visible,
like desktop icons, they don't fly across the screen from what
seems to be hyperspace to get into view.
https://bugzilla.gnome.org/show_bug.cgi?id=696323
if a slideshow file has a really large duration we'll currently
throw an exception.
This bug is aggravated by the fact that some versions of
gnome-desktop use UINT_MAX as a sentinel value to mean,
"don't ever update slide".
This commit treats durations that would overflow as infinitely
long.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
If a background gets requested from the cache while it's still
being loaded from an earlier call, then there will be two concurrent
loads of the same file.
That concurrency is mitigates the effectiveness of the cache and
also causes leaks.
This commit consolidates file loads so that concurrency doesn't
happen.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
Right now we only destroy the bgManager object when the
workspaceThumbnail is explicitly destroy with its destroy()
method.
This commit makes sure bgManager gets destroyed when the
workspaceThumbnail actor is destroyed without calling
destroy().
https://bugzilla.gnome.org/show_bug.cgi?id=696157
BackgroundManager connects to the changed signal in
the backgrounds it manages.
The signal ids for the changed signal connectionss are stored
as state on the background manager object.
If the background being managed changes while the manager
is still loading the old background, then the signal id
variable can get out of sync with the background object being
managed.
This commit ties the signal id to the background objects themselves,
so there is no opportunity for them to desynchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
Normally backgrounds get evicted from the cache when their actor is
destroyed. If the actor changes content without destroying itself,
though, we should evict the old content from the cache, too.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
We currently only add the first instance of a background
to the cache. This means if the actor associated with that
background is destroyed, the content will be evicted and
it will need to get reloaded, even if it's already loaded
on another actor.
This commit ensures every content gets added to the cache.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
In the (no barriers) fallback case handleDragOver has somehow
ended up being turned into a nop and thus breaking xdnd
overview opening.
Fix that by calling _toggleOverview() when a xdnd source triggers
it.
https://bugzilla.gnome.org/show_bug.cgi?id=696447
When commit 724a2bd7 changed the way to determine the default
calendar app, it dropped all special handling of evolution.
Unfortunately we still need it to not end up with the default
mail component, so add it back.
https://bugzilla.gnome.org/show_bug.cgi?id=696432
Currently, if a button-press event results in releasing the last modal
grab (e.g. clicks outside the grabbed actors), we don't consider the
event handled and allow its emission to continue. If we consider
dismissing a grab as an action of its own, any additional action
triggered by the same event becomes an unexpected side effect.
Tweak the capture handler accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=696422
There is no reason why there shouldn't be a battery icon in initial-setup,
knowing how much battery you have left is useful in during setup as well.
This also fixes an exception in the lock screen caused by the combined icon
not finding the battery one.
https://bugzilla.gnome.org/show_bug.cgi?id=696212
