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
If users click outside the search entry while it's empty we reset and
thus give up key focus. This means that when using an input method
with candidate popups, interacting with the popup with a mouse click
cancels the current input method context if there's no other text in
the entry besides the preedit string.
To avoid this we can check if the entry has preedit in addition to
checking if it has normal text.
https://bugzilla.gnome.org/show_bug.cgi?id=745167
Commit 5a47ad837b changed the definition of NC_() to include the
message context, so that gettext can correctly disambiguate strings
like "S". However this does only work when gettext actually returns
a translation from the catalogue; if the string is not found, we
need to strip the context again to not have it show up in the UI.
https://bugzilla.gnome.org/show_bug.cgi?id=745521
The mode is never set after the removal of the bottom tray, so it
no longer makes sense to pass it to allowKeybinding(). We can also
safely remove it from the ActionModes flags altogether without
requiring a synchronized update with gnome-settings-daemon, as
the latter never used any flag value above LOGIN_SCREEN.
Commit 1c1f63a7d7 changed the shadow
pipeline to use cogl_framebuffer_ortographic() instead of cogl_ortho(),
but the two functions take their arguments in a different order.
Fixes graphical corruption for text shadows in the login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=745061
When it comes to keybindings or gestures, there's not really a good
reason why popups associated with the top bar should behave differently
from any other shell menus. Just set the action mode generically for
all menus, so actions like screenshots or media-keys start working
with menus like the background- or app launcher context menus.
https://bugzilla.gnome.org/show_bug.cgi?id=745039
This is wasteful, since GResource does not support file monitoring.
Further, doing so will trigger a fallback code path in GLib that polls
every second in a thread, which is doubly wasteful.
https://bugzilla.gnome.org/show_bug.cgi?id=744013
Currently we have been using the vp8 codec because it was the best unencumbered codec at that time. With vp9 we now have a successor that leads to smaller
files at at the same video quality and has been supported by current browsers
for a while.
With the raise of hidpi and 4K displays we need a better codec that handles
those resolutions better, so switch to vp9.
https://bugzilla.gnome.org/show_bug.cgi?id=742744
The lookup table used by get_app_from_window_pid contained only pids of
apps launched by gnome-shell itself, but not pids of apps running before
gnome-shell was (re-)started. Also the pids in that table might not even
be the pid of the process that is actually showing the window if wrapper
scripts are used.
Instead use shell_window_tracker_get_app_from_pid which uses the pids
from the windows themselves.
This removes the only use of launched_pid_to_app which will be removed
in the following commit.
This fixes: https://bugzilla.gnome.org/show_bug.cgi?id=736527
g_dbus_proxy_new() (and library calls that wrap it) has an hardcoded
timeout of 25 seconds, which is insufficient for starting up e-s-r
in certain setups. Avoid a timeout error by starting the service
manually with a longer timeout before hand.
Also demote the error to a warning + exit failure instead of
a crash, to avoid triggering abrt reports.
https://bugzilla.gnome.org/show_bug.cgi?id=735308
Themes - namely the HighContrast one - may now request symbolic
icons rather than fullcolor ones. In order to have recoloring
work as expected in that case, we will need a theme node to pick
up colors from - using an StIcon instead of manually loading a
texture from the cache gives us that for free, so do that.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
GTK+ added support for a -gtk-icon-style property in themes to
enforce a particular icon style. Do the same for shell themes
with an -st-icon-style property, with the same set of possible
values as the GTK+ variant:
'requested' - use symbolic or fullcolor icon depending on the
icon name (default)
'regular' - enforce fullcolor icons
'symbolic' - enforce symbolic icons
https://bugzilla.gnome.org/show_bug.cgi?id=740447
The split between st_texture_cache_load_gicon() and load_gicon_with_colors()
no longer makes any sense, so just move the code into the public method.
https://bugzilla.gnome.org/show_bug.cgi?id=740447
Using a separate property to show when the application is busy rather
than cramming it into the state property makes the code clearer. In most
places we only care if an app is running or not, not whether it is
actually busy.
https://bugzilla.gnome.org/show_bug.cgi?id=736492
This simplifies the code and fixes a race where an application could
call g_application_mark_busy() before the shell subscribed to change
notifications on the application's busy state.
https://bugzilla.gnome.org/show_bug.cgi?id=736492
