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.
We currently only cancel the user verifier on reset if
verifying, but that means we don't properly cancel it when
asking for a username at the Not Listed screen.
The object already handles getting called when there is
nothing to cancel, so just cancel it unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=752438
shell_global_get_overrides_settings() may return %NULL in case of
custom shell modes (i.e. not the default and classic ones); while
this is not officially encouraged, we should still handle it rather
than throw an error.
https://bugzilla.gnome.org/show_bug.cgi?id=751921
The control center will call this method when the configuration dialog
for a display opens/closes, which will cause the same labels to quickly
fade out and in again, looking like it's flickering.
This commit fixes the issue by removing the tweens altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=751599
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
In some cases we might be allocated a size such that
this._grid.topPadding and this._grid.bottomPadding are both 0 which
means that the ScrollView fade effect gets removed. In that case don't
try to access the effect since it will be NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=750714
The menu items to move a window to the left/right workspaces were
removed when the window menu was implemented in GNOME Shell. This
is OK for the default vertical layout but not for alternatives.
https://bugzilla.gnome.org/show_bug.cgi?id=751344
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
And make these only handled on wayland. There's a plethora of issues
around touch passive grab and touch/pointer doubly handling to use
these right away on X11, so we stick to single-touch/pointer there.
This reverts commit 032a688a72.
https://bugzilla.gnome.org/show_bug.cgi?id=750287
Instead of using gnome-settings-daemon's D-Bus interface's presence.
iio-sensor-proxy now offers a D-Bus interface, which will exported
"HasAccelerometer = true" when an accelerometer is present.
https://bugzilla.gnome.org/show_bug.cgi?id=749671
Just reuse this gesture rather than implementing edge detection ourselves.
As a plus, we might get touchpad swipe support when Clutter handles it.
https://bugzilla.gnome.org/show_bug.cgi?id=749742
The menu is clearly associated with a particular window, so keeping
it around when the window is gone doesn't make sense - in case of
the window menu, it is actually harmful as every action will act on
the invalidated window and result in a crash. So just dismiss the
menu when the menu is unmanaged.
https://bugzilla.gnome.org/show_bug.cgi?id=749529
When chrome is added with the trackFullscreen parameter, the actor's
visibility will be updated automatically whenever its monitor's
fullscreen state changes. However as we currently ignore the fullscreen
state at the time the chrome is added, the initial visibility may well
be incorrect - fix this by updating the initial visibility as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=749383
