On request of GNOME Classic users, we add GNOME2-like workspace previews
when using a horizontal workspace layout. The previews scale a lot worse
than the menu though, with the risk that they take up all the available
width in extreme cases.
Address this by also taking the number of workspaces into account, and
switch to the menu when we have more than six.
This is particularly important now that we switched to a horizontal
layout by default.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/165>
Visibility changes are now handled internally, without an easy way
for us to hook into. We can resort to a hack though, as the gesture
action to bring up the keyboard is only enabled while the keyboard
is hidden.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/160>
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>
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 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
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
We mostly use the regular == and != comparison operators over their
type-safe === and !== counterparts. This is about to change, but there
are some places where we don't care whether a value is null, undefined
or 0; just check for falsiness there instead of using operators, so
we can start to consistently use the type-safe operators everywhere
else in a follow-up commit.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
As arrow functions have an implicit return value, an assignment of
this.foo = bar could have been intended as a this.foo === bar
comparison. To catch those errors, we will disallow these kinds
of assignments unless they are marked explicitly by an extra pair
of parentheses.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redundant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/91
Since version 1.50.0, gjs defines GObject.NotImplementedError for throwing
errors when a virtual method that requires a subclass implementation is not
defined.
So use this instead of a generic JS Error in such cases.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/84
Florian Müllner
Ray Strode
Sergio Costas
Milan Crha
Xiaoguang Wang
Marco Trevisan (Treviño)