The defaults have been shifted around so that the normal session
uses the regular schema and classic mode overrides it, so the
key is no longer present in 'org.gnome.shell.overrides'.
- make tree view scrollable when list grows large
- add some borders
- use symbolic icons instead of (deprecated) stock items
- adjust spacing/alignment
- disable remove button when no item is selected
https://bugzilla.gnome.org/show_bug.cgi?id=730843
- make tree view scrollable when list grows large
- add some borders
- use symbolic icons instead of (deprecated) stock items
- adjust spacing/alignment
- disable remove button when no item is selected
https://bugzilla.gnome.org/show_bug.cgi?id=730843
The default in gsettings-desktop-schemas has changed to not include
minimize and maximize to match the default of client-side decorations
in GTK+, so start overriding the setting to bring them back in classic
mode.
Currently the initial set of buttons is in stack/MRU order. To
avoid shuffling around the list each time it is disabled/re-enabled
(lock screen) or the group-mode settings changes, sort it by the
stable sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=719933
The 'launching' signal and this._onActivateOverride callback were
removed from gnome-shell in 7ecb5af587af7ed892c6cfc5af0858a2acb04905
and 7ecb5af587af7ed892c6cfc5af0858a2acb04905 respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=721864
MetaWindowActor.get_workspace() was removed, however the now used
MetaWindow.get_workspace() returns a MetaWorkspace rather than an
index, so can't be used directly.
https://bugzilla.gnome.org/show_bug.cgi?id=728820
The message tray is moved to the bottom-most monitor when there are
monitors below the primary monitor; in that case, we need to leave
the tray alone.
https://bugzilla.gnome.org/show_bug.cgi?id=728288
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
