This is something that gnome-panel supported, and apparently
some users would like to have it back, so restore this feature
on our window list too.
https://bugzilla.gnome.org/show_bug.cgi?id=723693
PopupBaseMenu provides a destroy() method that will destroy the menu
actor and make sure that the menu will be removed from the corresponding
PopupMenuManager (if any). We miss the latter when we destroy the menu
actor directly, so use the menu method instead.
https://bugzilla.gnome.org/show_bug.cgi?id=724688
Depending on the number of windows, AppButtons use different right-click
menus ("Minimize" vs. "Minimize all").
As the menu for the multiple-windows case remains the same, it is created
and added just once. However this means that in the single-window case,
the corresponding PopupMenuManager will track two menus for the same
source actor, resulting in various misbehaviors.
Fix these issues by adding and removing the app context menu appropriately,
so that the PopupMenuManager tracks a single menu at any time.
https://bugzilla.gnome.org/show_bug.cgi?id=724688
StButton takes the hover state into account to decide whether a
series of events should be considered a click. So when dismissing
a menu by clicking on a different window/app button, its menu
cannot be triggered before leaving and re-entering the button
(and thus syncing the hover state).
Fix this by always syncing the hover state after a grab is dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=724688
Applications now track all their windows, not just the ones that are
expected to show up in the window list. So to restore the previous
behavior, we now have to filter out windows with the skip-taskbar
hint ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=724134
While the list of windows in the left-click menu is filtered by
workspace, the minimize/maximize/close actions in the right-click
menu apply to all application windows on all workspaces.
This is fairly confusing, so restrict the actions to only apply
to windows that do appear in the left-click list.
https://bugzilla.gnome.org/show_bug.cgi?id=724134
Animate showing and hiding the window list when toggling the
overview (with a translation on and off the screen). Don't actually
change the visible status of the actor, because we don't want
to change struts.
In case of shadowed mounts, mounts can become uninteresting
after they are added, according to whether our handler or gvfs
runs first, so we need to watch for changes. The easiest way
is to create an item for all mounts, and only show the interesting
ones.
Default _ is gettext from gnome-shell domain, which doesn't have
the strings we need.
We could use mutter's, but translators already did their job
on pretty much all supported languages, so...
Shadow mounts are created by the GVolume infrastructure to wrap
daemon mounts managed by volume monitors, and are an implementation
detail that should not be exposed to the user.
gnome-panel's window list had context menus on buttons, that gave
easy access to common operations like close, minimize and maximize.
Add something similar to the window-list.
https://bugzilla.gnome.org/show_bug.cgi?id=699251
addActor() gone from PopupBaseMenuItem, arrows in menus,
SystemStatusButton gone.
The auto-move-windows cleanup is probably older, weird noone
noticed before.
Anyway, I need a pitch fork.
This can't work without a significant rework (because we can't
use GnomeRR in the mutter process, now that's DBus API implemented
by mutter itself, and the monitor config API is private to mutter
for now), and I doubt it's really useful to anyone.
Also, we have an orientation lock button, which kind of serves
a similar purpose
As part of the new unified status menu, the old status menu
was reworked considerably in 3.9.5, and the extension as it
was written does not make sense.
If hibernation is needed, it should be added (through another
extension) in the shutdown dialog.
Just like we look in XDG_DATA_DIRS, we should honor XDG_DATA_HOME
as well.
For compatibility reasons, we look in ~/.themes first, then ~/.local/share,
then /usr/share.
* remove unnecessary chromeHeight that breaks the system
* copy original _updateWindowPositions from 3.9
* use nativeWindowPlacement in update function
* tidy up NaturalWindowPlacement function
https://bugzilla.gnome.org/show_bug.cgi?id=699054
* use original realPositionWindows() and map _computeAllWindowSlots() to our function (_calculateWindowTransformationsNatural()).
* adapted _calculateWindowTransformationsNatural() to _computeAllWindowSlots()' behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=699054
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
Giovanni Campagna
Florian Müllner
Maciek Borzecki
Tim Lunn
Giovanni Campagna
Piotr Drąg
Jiro Matsuzawa
Wepmaschda