The REVERSES flag was removed from Meta.KeyBindingFlags a while ago, as
gnome-control-center doesn't recognize it and the corresponding "magic"
shift handling. That is, nowadays reversible keybindings need to
provide an explicit reversed binding.
https://bugzilla.gnome.org/show_bug.cgi?id=784079
The application can already be launched from the menu without further
confirmation from the user, so there is no security gain in asking the
user to trust it when launched from the desktop - just set the appropriate
attributes of the newly copied file to mark it as trusted to nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=781596
Someone mixed up add() and add_actor() - this has been present since the
the big rewrite based on the AxeMenu extension in commit 9211fa4409, so
there's little point in coming up with a replacement for something that
never had any effect to begin with ...
It's not very useful to allow dragging when there's no drop target,
so tie the functionality added in the previous commit to the presence
of a DESKTOP window.
https://bugzilla.gnome.org/show_bug.cgi?id=780371
Back in the olden days, it used to be possible to drag items from
the application menu to the desktop to create a launcher shortcut.
Reimplement that "classic" functionality in the apps menu extension.
https://bugzilla.gnome.org/show_bug.cgi?id=780371
The use of Array to keep track of inserted items is extremely
confusing, as no elements are ever added to the array. What
the code actually does is monkey-patching properties into an
empty object (that happens to be of type "Array"). While the
direct idiomatic replacement would be {}, update the code to
use a proper map instead.
https://bugzilla.gnome.org/show_bug.cgi?id=780371
There's no need to show the workspace indicator at the right
corner of the window-list if there's just a single workspace
AND the workspace creation is static. This saves us a bit more
of space.
https://bugzilla.gnome.org/show_bug.cgi?id=777504
The original extension author really hated the app switcher with a
passion and took over all its uses, but there's really no reason
to replace the 'switch-group' shortcuts - not least because the
window switcher doesn't implement switching between windows of
a single application. So just keep the extension to making the
'switch-application' shortcuts behave as 'switch-windows' for the
"classic" session (and all users who rather install an extension
than change shortcut settings).
https://bugzilla.gnome.org/show_bug.cgi?id=771531
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
