Use the new ::resource-base-path property on #GApplication to attempt to
load the menu layout of the application.
We look first at gtk/menus-appmenu.ui or gtk/menus-traditional.ui
depending on the setting of gtk_application_prefers_app_menu(). Failing
that, we fall back to the common case of gtk/menus.ui (which should
always be given). This provides a convenient way for application
authors to provide a different set of menus, depending on the desktop
environment they find themselves in.
As is the intention with other resources, if the resource base path is
unset, nothing will be loaded. Additionally, if the expected files are not
found, it is not an error -- just nothing happens.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
For the transition to work the box-shadows types in the shadow list
needs to be matched in various states so I'm using transparent shadows
istead of resetting them when not needed.
Keep Ctrol-Shift-D as a straight toggle-the-inspector keybinding,
but make Ctrl-Shift-I always bring up the inspector, and point
it at the widget under the pointer.
The way that GtkTextView et al pop up their context menu is to first
query to see if the clipboard has some text, and if so, enable the Paste
menu item. But since the Wayland backend hasn't had the greatest
selection and clipboard code, the callback for the clipboard got dropped
on the floor.
Add some simple code to respond to the TARGETS selection.
This makes right-clicking on a GtkTextView work fine.
Resize grips were introduced for GNOME 3.0, before we had any of the
"new GNOME app" features like invisible borders and CSD. With OS X 10.6
and 10.7, Apple has replaced the classic grips in their applications
with invisible borders as well.
New GNOME app designs don't use resize grips anymore and the new
default theme for GTK+, Adwaita, disables them entirely by forcing their
width and height to 0.
They're past their time. Remove the code to support them. This can
always be reverted if some app relies on them.
We decided in f8412eca34 that
we still need to react to these for a11y reasons, but left
the (then) harmless property deprecation in place. Now, the
deprecation causes runtime warnings for merely reading the
property, so drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=732667
