It may be 2015, but users still stumble upon the occasional .desktop
file that uses a filename encoding other than UTF-8. We currently
fail quite spectacularly in that case by not displaying any apps at
all - handle this case more gracefully, by only filtering out the
offending apps.
https://bugzilla.gnome.org/show_bug.cgi?id=651503
When the last interesting window of an app-backed window is removed,
we'll transition it back to STOPPED, but we transition the state and
send out the signal before we clear the running state.
This means that any listeners to the state-changed signal might
encounter a window-backed app that has a running state, but no
windows. If they call, e.g. shell_app_get_name, while in this state,
they'll encounter an assertion fail.
Apps that are starting might have uninteresting windows like splash
screens pop up and then go away (like LibreOffice), even when
startup-notification hasn't completed yet. In those cases, we don't
want to transition the app back to stopped -- it should remain in
the running state.
Our StartUpWMClass heuristics use a StartupWMClass -> .desktop ID
mapping built from the list of all installed applications. In case
of multiple .desktop files setting the same StartupWMClass, we
currently simply pick the last one returned by g_app_info_get_all (),
which can be a bit surprising:
A window with WM_CLASS 'emacs', launched through a .desktop file
named 'emacs.desktop' with a StartupWMClass of 'emacs' maps to ...
'emacsclient.desktop'!
Make this case a bit less random by preferring the app info whose
ID matches the StartupWMClass.
https://bugzilla.gnome.org/show_bug.cgi?id=751541
Use our own locking and queue instead of async_queue.
Implement unlock and unlock_stop to make the create function return
FLUSHING. This is important to be able to pause the pipeline after some
error occured in the pipeline.
Implement start/stop to clear the queue and its state.
Currently GNOME Shell doesn't support mnemonics and prompters may
send labels with it.
Remove the mnemonics indicator for now.
Signed-off-by: Stef Walter <stefw@redhat.com>
* Fixed style issue
https://bugzilla.gnome.org/show_bug.cgi?id=750465
libcaribou was designed to generate X events which works under wayland
sessions for X clients but obviously doesn't work for wayland clients
and for shell chrome.
This patch adds a simple caribou display adapter which inherits from
its X display adapter and allows us to continue to work for X clients
and at the same time makes the OSK work on shell text entries by
sending key events directly to the focused text actor.
Making the OSK work for wayland clients requires much bigger changes
at various levels in the stack and either not using libcaribou or
re-working it substantially so that's left for future work.
https://bugzilla.gnome.org/show_bug.cgi?id=747274
We currently don't have any code either in gnome-shell or
gnome-shell-extensions setting margins directly with the Clutter API.
On the other hand, the current behavior doesn't allow us to remove a
style class with margins and have that be reflected, so removing this
special casing seems like the right thing to do at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=746902
NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
The current code assumes that an embedded window will correspond to
a single MetaWindow over the entire lifetime of the icon, which is
incorrect - the embedded window is unmanaged on Unmap and a new
MetaWindow will be created the next time the embedded window is
mapped. As we currently ignore the new MetaWindow completely, it
will be shown normally in the scene instead of the embedded clone
as intended.
Fix this by setting up clone and window actor each time the embedded
window is mapped rather than once in shell_gtk_embed_set_window().
https://bugzilla.gnome.org/show_bug.cgi?id=745824
Each event returned by GetEvents includes the (currently unused)
UID, which is not always enough to unambiguously identify an event
(different calendar sources, recurring events, ...).
As we will start using the property to record events that have been
dismissed and should be persistently hidden from the calendar, change
it to a truly unique ID.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
