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...
Currently, we start gnome-shell in classic mode by passing
--mode=classic to the gnome-shell command line. This --mode=classic
gets stripped away when the session is saved, which breaks classic
mode on subsequent login attempts.
This commit changes the session file to set the
GNOME_SHELL_SESSION_MODE environment variable instead.
https://bugzilla.gnome.org/show_bug.cgi?id=720894
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.
