Commit 2667b9f3e5 updated the extension for a shell change that
renamed _onActivate() to _activate, but forgot to also rename the
declaration of the variable that stores the original function.
Fix this to stop a warning about assignment to an undefined variable.
https://bugzilla.gnome.org/show_bug.cgi?id=745470
The point of that code is to keep the window-list underneath
modals' lightboxes if possible (i.e. unless the OSK is shown).
The trayBox was a natural pick back in the day, but the panel
will do just as well ...
https://bugzilla.gnome.org/show_bug.cgi?id=745304
MetaWindow.title might be NULL, particularly for Wayland clients where
setting the title is a request separate from window creation. We
shouldn't try to set StLabel's text prop in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=745064
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
Notification banners are now displayed at the top, and the summary
moved into the date and time drop down - the bottom is ours now,
no more special sauce needed to interact with it gracefully.
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
Classic mode uses a different overrides schema, so make sure we use the
correct setting instead of hardcoding the usual org.gnome.shell.overrides
schema.
https://bugzilla.gnome.org/show_bug.cgi?id=737486
A new setting "show-on-all-monitors" (false by default) is available to
show window lists on all connected monitors.
The Extension object monitors conditions that require the list of
windows to be rebuilt. The WindowList and Button classes have a new
"perMonitor" property that indicates they should handle windows on
their own monitor only.
https://bugzilla.gnome.org/show_bug.cgi?id=737486
BaseButton is a new class that shares the common logic of WindowButton
and AppButton. AppButton is passed to AppContextMenu so that it can reuse
code from the now public getWindowList() method.
https://bugzilla.gnome.org/show_bug.cgi?id=737486
setThemeStylesheet() stopped accepting %null to revert to the default
stylesheet. The issue is fixed in gnome-shell master, but work around
it for 3.15.2 to not ship broken (again).
Move messageTray patching form the Extension object to the WindowList
class. Moreover, only do the patching if the window list is on the bottom
monitor. This refactoring will make it easier to have several instances
of WindowList (one on each monitor).
https://bugzilla.gnome.org/show_bug.cgi?id=737486
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
Florian Müllner
Rui Matos
Sylvain Pasche
Maxime Henrion
Adel Gadllah
Debarshi Ray