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
