This may be the case where keyboardIndex is -1, which may be the
case where either the keyboard monitor hasn't been set yet, or
the keyboard is being unmanaged and meta_window_get_monitor
returns -1
https://bugzilla.gnome.org/show_bug.cgi?id=788882
(cherry picked from commit 19e864ed3b85278ed1a9527ce3c29646328c19ec)
Calling meta_window_get_monitor on an unmanaged window may return
-1, so we need to check the return value.
https://bugzilla.gnome.org/show_bug.cgi?id=788882
(cherry picked from commit c9bf72c5c4e8a94ff66fd191cb79165bed2831e5)
During global grabs, actors miss enter and leave events required
for correct hover tracking. This can cause the workspace switcher
to get stuck while slid out, so ensure the actor's hover state is
synced after drag operations.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/161
(cherry picked from commit 328c63bf64ef13f477156db2ae1c657957259130)
Showing and hiding children does not affect the allocation of the uiGroup
nor its other children. We can avoid full relayout/redraw in those
situations.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/197
(cherry picked from commit 73d8c82640f6125cfbf80b791769a6e3903d6c0c)
The actor allocation doesn't change per-se, but apply_transform()
will practically transform it. In order to have the paint volume
update accordingly, queue a relayout.
(cherry picked from commit ab4c72d758a23824e8e4a2f35d0b5b479777f294)
The default get_paint_volume() implementation will do the union
of children, and the child ClutterText paint volume may expand
beyond StEntry size when text overflows.
We actually want all content to be clipped to the StEntry, so
implement get_paint_volume() and tell it so.
(cherry picked from commit 86a520b880808ad18d397ab8e7a7a05b1a8b4e4c)
And constrain it in StScrollView instead (instead of falling back to an
infinite paint volume, as the actor as paint/pick impls, but no
corresponding get_paint_volume one).
Fixes artifacts with the AppView (and possibly other places) when paint
volumes are aggressively cached.
(cherry picked from commit 4bf033a8853591e9f739b2a067009698e476f7e9)
For windows, the cursor location needs to be adjusted by the frame
offsets. However we cannot assume that there is a window, as the
shell itself can have the key focus.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/414
(cherry picked from commit 0dee82fb9fa974ebdb4dd77fd85535a6edf207fd)
When a dialog is added to a window while the overview is shown, we get
its parent using get_transient_for() so we can add it to the right
window clone.
If we have multiple layers of dialogs we have to do this recursively
until we find the root ancestor. This case currently results in an
infinite loop: Since parent is always set to the same window, the
while-condition will always be true.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/180
(cherry picked from commit 52cbc299a795b4573a7558982115354cfa7a4e61)
We show a cover pane on top of the overview during transitions to
prevent issues caused by clicks and mouseover events when the overview
is not ready. Right now, this pane is only being shown on the primary
monitor, which obviosly allows interactions to happen before the
animations are finished on the secondary monitors.
To fix this, use the size of the whole stage for the cover pane.
(cherry picked from commit 02d06bb1f386d7d35e8d830769243490b3953983)
Instead of consuming the event in front of the input method. Enter
is sometimes overriden by those, so it seems better to let the IM
handle the key event, and react later to it if it got propagated
anyway. That is what ::activate does, so use this signal.
This used to work before ClutterInputMethod/InputFocus because the
IM received the events directly from stage captured events. This
is not the case anymore.
Closes: #440
(cherry picked from commit 3ab9e9e8adfb2093ade470c26ecb761dde89fe49)
It is unclear what the change was supposed to be fixing, but it
broke animations of workspace additions and removals, as those
events trigger the ::workareas-changed signal.
This reverts commit c29bd46e7a7e37a83849df8b3186c84eb46679ac.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/162
Maximized and tiled windows can be restored with a drag gesture,
not only from their titlebars, but also from any non-reactive
parts of the top bar above the window. Currently this only works
for actual pointer devices, extend the behavior to handle touch
as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/112
(cherry picked from commit 905801b178fffa13cf1161b1ccfc8b1202f97efc)
Key events involved in a keyboard shortcut are not completely consumed by
Mutter. That means that if the popupMenu is bound to a shortcut (e.g.
Alt<Space>) and the user keeps the keys pressed, the same key-event will be
delivered to the popupMenu. We can workaround this issue filtering out all the
events where a a modifier is down (except capslock).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/372
(cherry picked from commit 2e90c5fa4b35ebe26c694223966834ee949cfce3)
When in lockscreen mode there's no point of resetting the auth login as there's
no welcome screen, and that would just cause the UI to freeze, with no reason.
This could have been useful if we were stopping the user to login for a given
time after ALLOWED_FAILURES attempts, but this is not the case yet.
(cherry picked from commit cf69fe4b18e9ecf5d33de42c636a42950a1c7cd8)
Set the sensitivity of the UI according to the canRetry parameter and thus
if no more logins are allowed don't take any input.
Fixes#311
(cherry picked from commit 8f848925f6cdae0d96c355faa8acc2b0d45ab16c)
When we get a reset signal the preemptiveAnswer should be also unset or it will
be used next time the user authPrompt will be activated, even without any further
user interaction.
Fixes#311
(cherry picked from commit d21657fe61f9a41734554811c29c54979ca2dbb9)
Destroying and recreating the entire events list on every change is not only
wasteful, it also breaks the clear functionality as messages scheduled for
removal are replaced with "new" messages after the first message has been
removed.
Address both issues by keeping track of all messages and re-use them
whenever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/325
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
And stop using FocusCaretTracker for caret position purposes. This
new object uses 1) the text-input protocol in wayland and 2) Info
from IBusPanelService for X11 (which is meant to work for XIM too).
This drops the usage of AtspiEventListener for OSK purposes, which
is best to avoid.
Modes, extensions and other GNOME Shell assets are searched in appropriate
subdirectories of each directory in XDG_DATA_DIRS, falling back
to global.datadir.
However, this isn't the case for themes, which are currently always expected
in global.datadir, even when referenced by a mode in a different XDG_DATA_DIR.
The fix is to have the theme finding pattern follow the same logic as other
elements.
Fixes#167.
(cherry picked from commit d6d09fd3c82dd39dac1a764073040b57baeb8659)
The default keyed_surface is meant to handle CoglTextures thus we can't
add cairo surfaces to it, as the DestroyNotify function won't handle them.
Then the quicker way is to just add another Hash table for handling
such types of textures, with proper destroy function.
(cherry picked from commit 1f03599d1cf888f73a33363212b99905064e2c9e)
This might cause a crash when cleaning up the cache as the hash table has
cogl_object_unref as DestroyNotify function but that assumes that
the passed object is a valid CoglObject.
Fixes: #210
(cherry picked from commit a24999b7a317483d20a4df0abdf04f40f9bf95ed)
These variables are in fact used from other modules, so gjs complains about them
being const.
(cherry picked from commit 8237a1f6e002266696eb93e7cf15d3be7191585f)
The instance is owned by the actor (being its child), and thus when the
disposal happens for the parent the text is disposed too, thus it's just
safer to nullify its reference so that we won't try to access to invalid
objects later, and this might be the case since the JS objects could be kept
around until they aren't finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=788931
(cherry picked from commit 44894262f49b9f8b2809321ebcf1cd9426303fd6)
Similar to what it's done when the main connection changes, we need
to make sure that the icon in the panel gets updated before calling
_syncConnectivity(), so that the icon gets always updated if needed,
regardless of whether there's an active connection or not.
This is needed because there's at least one case when an icon should
be shown when the computer is not connected to any network: when a
hotspot has been enabled, which can be useful even if there's not
an internet connection to share (e.g. to easily allow connecting
other devices to the computer.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/214
(cherry picked from commit d8b9e23502ad763329c75659387c21fb9084de57)
While the libnm-glib version of the function returns a GByteArray*
that gjs can directly cast to the required gutf8*, the libnm function
returns GBytes* from which we need to explicitly fetch the data.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/136
(cherry picked from commit c0a453f64f4c725e520830b2cdba8a608acc94e4)
commit 642107a2 attempts to avoid resetting the current keymap on
spurious input source changes.
It does this by checking if the current layout id is found in
the new list of layouts and resetting the current layout to the
associated match in the list. By not nullifying the current
layout, it won't get subsequently reset.
Unfortunately, if the order of the list changes, resetting the
current keymap is still necessary, since the order corresponds
with the index of the activated group.
This commit changes the code to nullify the current layout if
its group index changes.
https://bugzilla.redhat.com/show_bug.cgi?id=1573923
The IM can pretty much update the input sources anytime (even if
to set the same ones). That ends up triggering rebuilding all user
defined keymaps, and losing modifier state if we are unfortunate
enough that this caught us while pressing one.
One common situation seems to be password entries, resulting in
the wrong character being printed if the first character happens
to require the shift key.
If the current keymap is not found in the newly loaded list,
this._current will end up null, with the same behavior as we get
currently (immediate keymap reload).
https://bugzilla.redhat.com/show_bug.cgi?id=1569211https://gitlab.gnome.org/GNOME/gnome-shell/issues/240Closes: #240
We use the close() method to disconnect signal handlers set up in
init(), however the handler ID is only valid in the first call in
case the method is called more than once.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/221
Otherwise it happens that porthole is computed again after that the
overlay is hidden (triggered by a layout reallocation) and thus not
regenerated again afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=792687
(cherry picked from commit 5fcf40b973286fd442148ee3348becd493c8206d)
