We currently assume that the application associated with a particular
window is fixed. While this holds true for almost every application,
there are some cases of multi-app-packages like LibreOffice where
windows may change the properties used for application matching at
runtime. Catch those cases to make sure we display the correct icon
when the window shifts applications.
https://bugzilla.gnome.org/show_bug.cgi?id=771731
.desktop files in non-standard locations are not handled by GIO,
so looking up apps for entries for such locations (e.g. a
directory added via the AppsDir directive) will fail. We can
still handle this case in the menu by creating the app directly
from the entry's AppInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=762206
The code de-duplication in commit bf8d30603e57b broke the extension,
fix by duplicating the code here now :-(
(It's not really that bad though ...)
https://bugzilla.gnome.org/show_bug.cgi?id=767077
The new logical dimensions are reported in the overlay, rather than the
pixel dimensions. That is: if scaleFactor is 2, a window might be
resized to 2400×1350 device pixels, which will be reported as 1200×675
in the overlay.
This is consistent with (for example) the DevTools in Chrome, which
reports the logical size of the viewport when you resize the window,
rather than the physical pixel size.
Tested with a freely-resizable window and with a constrained-geometry
window (GNOME Terminal), on a hidpi display.
https://bugzilla.gnome.org/show_bug.cgi?id=754607
GMenu's TreeEntries return an AppInfo that is created from the
.desktop filename, not from a desktop ID as expected by the
AppSystem. As a result, g_app_info_get_id() will simply return
the file's basename, which only matches the desktop ID if no
prefix-to-subdirectory mapping as described in the menu spec
is involved.
Fix this by basing the app lookup on the entry's desktop ID instead
of the AppInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=759004
Category items grab the pointer to implement "triangle navigation", which
interferes with automatic hover tracking in other widgets. While this is
the correct behavior while we hold the grab (i.e. when crossing other
category items without switching), it can interfere with user expectation
when the grab is dropped, as the motion event that causes us to do so
doesn't necessarily occur before the "target"'s enter event - address this
by syncing up the hover state manually after dropping the grab.
https://bugzilla.gnome.org/show_bug.cgi?id=754959
Independent from the grouping mode, the window-list currently shows
up as a series of "push buttons" in screen readers, which is obviously
not useful, so point to the correct labels.
https://bugzilla.gnome.org/show_bug.cgi?id=755223
The user explicitly enabling desktop icons is a pretty good hint
that she intends to use the Desktop folder, so be consistent with
GTK+ and nautilus and include it when the corresponding setting
is true.
https://bugzilla.gnome.org/show_bug.cgi?id=754578
The indicator numbers workspaces starting from 1, while newly added
workspace names in the preference dialog start counting at 0.
Change the latter to be consistent with the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=753105
It is odd to consider windows that are not shown in the window list
for app sorting, in particular when switching between grouped and
ungrouped mode, and when a long-lived window like the DESKTOP is
present.
https://bugzilla.gnome.org/show_bug.cgi?id=753055
Just like the top bar, the window list should scale according to
the font scaling factor, so convert the existing pixel sizes into
font-relative ones.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The window list position depends on both the monitor geometry and the
list height, however changes to the latter are currently ignored. For
the time being this doesn't matter due to the list's fixed height, but
we are about to scale the list with the text, so reposition the list
on height changes.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The window-list's fixed height currently allows us to get away without
expanding buttons, however this won't be the case anymore once we start
adapting the list with the text scaling. So fix up the code to do what
was always the intention anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=703585
The function never had a timestamp parameter, the parameter that was
added at some point is a workspace index. Ouch, this has gone unspotted
since the original AxeMenu extension was adapted for the apps-menu ...
For a while now, gnome-shell has initialized extensions before
setting up its own keybinding handling. As a result, our taking
over of the panel-main-menu shortcut will be overwritten when
the extension is enabled at startup - work around this by setting
up the keybinding again on LayoutManager::startup-complete.
https://bugzilla.gnome.org/show_bug.cgi?id=746639
Setting up signal handlers inside a class and rely on outside code
to disconnect them via global variables is utterly weird. Just
disconnect everything inside the class when the corresponding actor
is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=746639
By default, PanelMenu.Button creates a popup menu with arrow side TOP
which is wrong in our case and can mess up BoxPointer's positioning.
We can work around that easily by creating the menu ourselves with the
correct arrow side.
https://bugzilla.gnome.org/show_bug.cgi?id=746365
Menus in the top bar have some margin at the bottom, to prevent
menus to extend all the way to the bottom edge as the expand; we
obviously don't want the same behavior in the window-list at the
bottom, so stop pretending to be a top bar menu.
https://bugzilla.gnome.org/show_bug.cgi?id=745952
The systemMonitor extension extends the message tray with its UI, which
obviously broke when the bottom tray was removed. It has also been the
source for various performance/memory issues in the past and is part of
the semi-random collection that pre-dates the extension.gnome.org site
rather than the set of classic-mode/endorsed extensions, so just remove
it from the module.
Hopefully this will motivate someone who actually cares about it to pick
it up ...
https://bugzilla.gnome.org/show_bug.cgi?id=745195
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
