Some default values differ between classic and normal sessions. We
used to implement this by overriding the shell's default values in
mini-extensions (or more precisely: reversing the shell's overrides).
Use a mode-specific overridesSchema instead, which has the advantage
that settings defaults will not change unexpectedly when extensions
are disabled/enabled (for instance during screen locks).
https://bugzilla.gnome.org/show_bug.cgi?id=701717
* use original realPositionWindows() and map _computeAllWindowSlots() to our function (_calculateWindowTransformationsNatural()).
* adapted _calculateWindowTransformationsNatural() to _computeAllWindowSlots()' behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=699054
When the number of workspaces changes, we clear the existing menu
and recreate it based on the screen::n-workspaces property, so it
is slightly more correct to track changes to the property directly
instead of using the workspace-added/workspace-removed signals.
This change also fixes a corner case, where changes to the property
before workspaces are initialized are missed and we end up with the
wrong number of workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=699350
In addition to "always" and "never", gnome-panel supported an "auto"
grouping mode, which only started to group items when running out of
available space. It makes sense for us to support the same option in
the window-list extension, so implement it.
https://bugzilla.gnome.org/show_bug.cgi?id=697157
-st-natural-width is useful to request a larger-than-usual width,
add back the max-width removed in commit 702cf52cfc to also request
a smaller-than-usual width as necessary.
Items in the window list should take up a fixed amount of space
unless the list is full and items need to shrink. To achieve this,
replace the max-width with the newly added -st-natural-width.
https://bugzilla.gnome.org/show_bug.cgi?id=695392
This is the most basic version of a workspace switcher, taken from
Frippery Bottom Panel and adapted. It handles clicks and scrolls,
and does not show window thumbnails or shapes.
Note that, differently from the frippery version, it won't change
the workspace layout, and actually assume a linear vertical layout,
which is then shown horizontally. This is to keep compatibility
with the overview, which uses a vertical layout.
https://bugzilla.gnome.org/show_bug.cgi?id=694914
PanelMenu.Button listens to key-press-events on the corresponding
menu to move focus to neighboring buttons on left/right arrow. In
order to allow keynav from the category list on the left to the
application list on the right and vice-versa, we may need to suppress
the parent behavior depending on the currently focused actor, so
overwrite the signal handler accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=693074
When setting GtkRadioButton's group property, its active property is
also set as a by-product. This means that setting these properties
isn't commutative which arguably is a bug in gtk+ but one that we can
easily work around by just switching the order here.
https://bugzilla.gnome.org/show_bug.cgi?id=697495
When grouping is enabled, items that are only have a single window
associated are still expected to behave like ungrouped items.
This includes activating windows by DND, which uses the metaWindow
property on the hovered actor's _delegate, so make sure it is set
on AppButtons in single-window mode as well.
https://bugzilla.gnome.org/show_bug.cgi?id=693561
Implement a keep-up triangle to keep submenus from changing if the
pointer strays a bit when mousing towards the application list on the
right. The keep-up triangle is only used if the mouse movement is more
horizontal than vertical.
This is similar to the behaviour of GtkMenu, but much more simple
because we are only dealing one specific kind of menu, and hence don't
need to be as generic.
https://bugzilla.gnome.org/show_bug.cgi?id=692913
LayoutManager will take care of our visibility, but we need to
adjust the message tray anchor point manually. Also, we must not
show ourselves when coming out of the overview if we're in fullscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=696929
