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.
The resize grip code in GTK+ likes to call gdk_window_raise a lot. The
unfortunate side effect of gdk_window_raise is that it queues an
invalidation on the entire window, even if it's already the topmost
child.
Add a return value to gdk_window_raise_internal, and only queue the
invalidation if the raise had an effect.
Otherwise, a user that calls gdk_window_resize (window, 0, 0); over and
over won't properly fizzle out, and will queue a redraw. Clipped, but
still. These redraws can be chatty on some platforms like Wayland, and
there's no good reason to not avoid them.
This was the case for resize grips.
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 need to enclose paths containing $(BinDir) with double quotes as it
points to something like c:\foo\gtk+-x.yy.zz, which the copy command on
Windows does not like "+" in paths unless enclosed in quotes.
As the Visual Studio 2012/2013 are only slightly different from the Visual
Studio 2010 projects, we can provide support for them by using scripts to
copy the Visual Studio 2010 projects, and update the specific parts as
necessary.
Thus, there would be little maintenance overhead for these as only the 2010
projects need to be kept up-to-date as a result. This might change when we
do get the stack working with WinRT/Metro, but that's going to be another
totally different issue.
The stock icons are now built into the GTK+ DLL via resources, so don't
try to install the stock icons, and the icons don't reside in their former
positions anymore, causing messages indicating that the files cannot be
found.
This reverts commit 2e0ce67f8a.
Since g-i 1.40.0 we are using the .lib file(s) to determine the DLL(s) that
the introspection files should look for, instead of directly using the
DLL(s) directly, so it is no longer necessary to make copies of the GDK
.lib file to match the <namespace-name>-<namespace-version> convention when
we are building the introspection files for GdkWin32. Remove that from the
introspection build process as a result.
