If a user is in the middle of a drag in the window list and the
window list associated with the drag gets destroyed, the drag
monitor gets leaked.
Later when the drag motion is processed, spew goes to the log:
clutter_actor_contains: assertion 'CLUTTER_IS_ACTOR (self)' failed
Examples of triggers for this bug:
- The monitor topology changes
- The screen gets locked during the drag
This commit fixes the spew and the leak by ensuring any pending
drag monitoring is disabled when the window lists are destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/145>
We modify gnome-shell's workspace tracker to only remove empty
workspaces from the end. However we currently don't take into
account that sticky windows appear on all workspaces, so those
are preventing any workspace from getting removed at the moment.
Exclude them when determining whether a workspace is empty to
get the expected behavior.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/135
The current code positions window previews explicitly using a fixed
layout manager. For that it relies on a valid parent allocation,
which is error-prone and frequently results in warnings.
Address this by moving the positioning code into a custom layout
manager, and only update the visibility from the window preview.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/260
The current code positions window previews explicitly using a fixed
layout manager. For that it relies on a valid parent allocation,
which is error-prone and frequently results in warnings.
Address this by moving the positioning code into a custom layout
manager, and only update the visibility from the window preview.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/260
Although window-list checks the 'skip-taskbar' property when a
window is added to the desktop to decide wether it should be
shown in the bar or not, it doesn't honor that when the property
is changed after a window has already been added. Since the new
WaylandClient API allows to change this property for already
mapped windows, supporting this is a good idea.
This patch fixes this.
Fix https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/130
Since PanelMenu.Button started to inherit from St.Widget, the custom
_allocate() function isn't called anymore.
Simply changing the function to vfunc_allocate() doesn't work as other
changes happened in the meantime, so for now just remove it altogether.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/124
The current widget uses UI patterns that are reminiscent of GNOME 2.
It doesn't take a lot to make it look more modern: Simply giving the
radio group a distinct background and border allows us to move the
whole UI to the center, making the dialog more balanced and visually
pleasing.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/121
While we don't endorse or support 3rd party theming, the extension
exists and is actively used. However right now the most convenient
way of setting it up is by installing Tweak Tool; give users an
alternative by providing a simple settings dialog ourselves.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/117
The buttons currently appear more as an attachment to the label
than as distinct controls. Address that by:
- applying .button styling
- increasing spacing between label and button
- aligning buttons at the end
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/223
While window titles really really shouldn't contain newline characters,
they are under application control and therefore may very well do.
Force the corresponding labels to be single line, to prevent offending
applications from messing up the whole window list layout.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/202
When cycling through window sizes, we should skip any sizes that are
bigger than the available area. We do that, but the current code
assumes that the possible sizes are sorted, which is no longer the
case since the addition of "phone" sizes in commit 5b43d4733c.
As a result, we may now skip sizes that would fit perfectly fine.
Address this by filtering out invalid sizes beforehand instead of
assuming a certain order (wich no longer work due to the addition
of a portrait format).
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/97
While nautilus removed its desktop support a while ago in favor of an
extension, it's still possible that some external X11 desktop icon app
is used. As DESKTOP windows cannot be moved between workspaces or stacked,
and aren't perceived as regular windows, it doesn't make sense to show
them as previews in the workspace switcher.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/93
While nautilus removed its desktop support a while ago in favor of an
extension, it's still possible that some external X11 desktop icon app
is used. As DESKTOP windows cannot be moved between workspaces or stacked,
and aren't perceived as regular windows, it doesn't make sense to show
them as previews in the workspace switcher.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/93
