While rare, it is possible to have a window not associated with any app
(not even a fake window-based one). We currently throw an error when
trying to set the icon for such a window, so handle this case and
use a fallback icon instead of the app icon.
https://bugzilla.gnome.org/show_bug.cgi?id=743401
Currently the window-list will be stacked above system modal dialogs,
which means it is not dimmed like the rest of the desktop and remains
accessible to interaction. We cannot do any better when showing the
on-screen keyboard, as we need to keep ourselves above to not end up
covered by the OSK, and the keyboard itself is stacked above modal
dialogs to allow its use for input. However we can at least fix the
case when not using the OSK.
https://bugzilla.gnome.org/show_bug.cgi?id=740722
Currently when using auto-grouping, the list is ungrouped each
time a window is closed, and then possibly re-grouped on the next
allocation - as a result, there is a brief "ungroup flash" if the
list is supposed to remain grouped.
Avoid this by computing the width the ungrouped list would have
rather than by actually ungrouping it.
https://bugzilla.gnome.org/show_bug.cgi?id=738286
Since commit 191c7ccc24, we check whether we already have a window
in the list before re-adding it on MetaWorkspace::window-added.
We can do something similar on MetaWorkspace::window-removed to
avoid some extra work when a window is moved between workspaces
rather than destroyed.
The list returned may contain windows that are being destroyed.
The ShellGlobal method filters those out, so use that instead; we
should eventually stop looking at window actors when we want windows,
but for now this is the easy and safe thing to do.
Rather than re-implementing the function (and risk missing improvements
like the launch animation), call the original one as if the user had
middle-clicked the launcher.
We do need to inject our own handler to treat application-switch
actions the same way as the corresponding window-switch ones;
we can actually express exactly this without re-implementing the
entire function, by calling the original handler with a tweaked
action parameter - the resulting code is not only more concise,
but should also be a bit more robust against changes in core.
https://bugzilla.gnome.org/show_bug.cgi?id=737457
Since shell commit dd85670f8b25, the handler got a return value to
determine whether Escape should be handled automatically; we do
want this for the window switcher, so add an appropriate return
value to restore the expected behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=737457
When a window's on-all-workspaces property changes to true, the
workspaces the window was not located on will emit the ::window-added
signal for the window; however we don't want multiple buttons for
the same window, so filter out the extra calls.
https://bugzilla.gnome.org/show_bug.cgi?id=736398
The workspace button used to extend to the bottom edge, which of
course is A Good Thing (tm) - commit ec8f269107 broke this when
it added an additional container to the hierarchy, expand the
button again to bring back the old mouse-friendly behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=708247
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
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
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
