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
.scrollbars-junction borders were removed by setting border-stylei: none,
it interacted (why?) with the scrollbars on sidebar, making the border
transparent seems not to have side effects there.
When showing and hiding the inspector window repeatedly without
dismissing the dialog, we were hiding the inspector, but not
the dialog, leading to a confusing user experience.
https://bugzilla.gnome.org/show_bug.cgi?id=732443
Applications can call this to determine if they should an app menu.
This will be %FALSE on desktop environments that do not have an
application menu like the one in gnome-shell. It is %FALSE on Windows
and Mac OS.
Applications are completely free to totally ignore this API -- it is
only provided as a hint to help applications that may be interested in
supporting non-GNOME platforms with a more native 'look and feel'.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
We were only setting the state transiently in ::draw, leading
to various drawing anomalies, such as labels not picking up
the appropriate color from BUTTON styles.
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
When there area explicitly added buttons in the action area,
we were trying to ensure that the action area is visible,
but failed, since we are now hiding the action_box. Fix it
by showing the action_box when things are left in the action
area.
We don't set use-header-bar for message dialogs, since we
want the buttons in the action area, but we do want a nice
rounded csd titlebar. Add back the box that was used before
to achieve this, when appropriate.
Give GtkAboutDialog buttons in the action area instead of hard-coding
use-header-bar to TRUE. This is for environments which don't have the
Gtk/DialogsUseHeader xsetting turned on.
https://bugzilla.gnome.org/show_bug.cgi?id=730893
We use gtk_adjustment_enable_animation to enable animated
updates of the adjustments. Currently, this is enabled
unconditionally, and with a duration that is hardcoded.
https://bugzilla.gnome.org/show_bug.cgi?id=732376
