It replaces the recently added GtkRange:primary-button-warps-slider
style property. Implement the setting in the quartz backend,
it proxies the "click in the scroll bar to" property from the
OS X PrefPane.
cc7abf6a1c introduced the
primary-button-warps-slider style property, but with a different
condition check than the GTK3 counterpart.
It turns out we really need to check for the mouse click location here,
or we'll warp the slider to pointer also in case we clicked on the
slider itself.
https://bugzilla.gnome.org/show_bug.cgi?id=683512
Since the ::changed implementation of GtkRecentManager implies a
synchronous write operation, when we receive multiple requests to emit a
::changed signal we might end up blocking.
This change coalesces multiple ::changed emission requests using the
following sequence:
• the first request will install a timeout in 250 ms, which will
emit the ::changed signal
• each further request while the timeout has not been emitted
will increase a counter
‣ if the counter reaches 250 before the timeout has been
emitted, then the RecentManager will remove the timeout
source and force a signal emission and reset the counter
This sequence should guarantee that frequent ::changed emission requests
are coalesced, and also guarantee that we don't let them dangle for too
long.
https://bugzilla.gnome.org/show_bug.cgi?id=616997
A call to scrollRect must be followed by a call to set that the offset
rect needs display for the changes to "take effect". This was not
done prior to this patch which, in some cases, caused corruption during
scrolling.
get_time_from_ns_event(): apply patch from Michael Hutchinson which
makes sure the returned guint32 wraps correctly on 32 bit machines
when the uptime exceeds 2^32 ms.
(cherry picked from commit 78506bd604)
This was showing up when using a combo box in list mode. After popping
up the list, the keyboard grab appeared stuck. What was stuck here is
only the client-side grab, since we forgot to clean up our grabs
when receiving an UnmapNotify.
This bug was introduced in 3f6592f60f.
[ Alexandre Rostovtsev <tetromino@gentoo.org>: backport to 2.24 ]
https://bugzilla.gnome.org/show_bug.cgi?id=680346
Add a GtkRC option to select for an LTR/RTL widget direction in the
pixbuf engine; this will allow the engine to apply different theming
assets according to the text direction, which is useful when theming
e.g. a spinbutton or a combobox entry.
Implement a special case for the root window, which has to be handled
differently on OS X.
Contains some bit fiddling corrections by Kristian Rietveld.
Beforehand, the check whether or not emission is necessary was done
based on the "uninitialized" window position in the top left corner.
We now wait until the window size is set for the first time, to avoid
emitting EnterNotify when it is not necessary.
Accept a :-separated list of module names in GTK_IM_MODULE and
the corresponding setting, to deal a bit better with broken
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=603559
Patch by Akira Tagoh, backported from GTK+ 3. The backport
is required because GTK+ 2 and 3 are listening to the same env
vars and settings for immodules.
Demos in gtk-demo are supposed to be exemplary. However, if one were to
give them dummy main functions many of them would not compile with
-DGSEAL_ENABLE. This changes the demos to make them use accessor
functions whenever possible instead of direct changes to the struct
members.
http://bugzilla.gnome.org/show_bug.cgi?id=667155
Explicitly return FALSE in selection_set_compound_text() to
indicate that we don't want to support compound text selections;
this will eliminate the "not implemented" warning for quartz.
This pushes the clipboard contents to the OS X clipboard when the
application is quit. Without doing this, clipboard data set by a GTK+
application cannot be accessed after the clipboard has been quit.
Currently, we implement this the easy way because the clipboard
support is fully implemented in GTK+. In the future this might change.
Before, right click events were still let through into GDK. In this
case, also middle/right button events with x-coordinates in the range
[-3, 0] are processed, resulting in failures/crashes in the window
finding code because no GdkWindows are present in this range.
Turn dead_doubleacute plus space into '"' and not into a double
acute because that's the way to enter double quotes on the
US-International keyboard layout.
The window's role is 'GtkFileChooserDialog', so that window managers can match it
for positioning.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Having refactored cups_request_printer_list_cb so that the cups
version-dependent block size is small enough to be handled in a single
ifdef, make the ifdef HAVE_CUPS_API_1_6 block
So that it can be passed as a single parameter to functions as we
extract-function to make cups_request_printer_list_cb more manageable.
Note that not all of the affected variables are changed in this
changeset. Those are in extracted functions and will be addressed in the
next two changes.
In GTK+ 2, child widgets don't get unmapped, and yet, that is when we were trying to
save the settings of GtkFileChooserDefault. Now we connect to the toplevel's
unmap signal and do the right thing there.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Of course, we must pass coordinates in the NSWindow coordinate system
when creating an NSEvent. This fixes drag icon positioning and makes
the icon slide back to the correct position when the drag is
canceled.
In the Quartz backend, there are two methods by which windows are
resized. The first method is fully handled by Quartz and does not appear
in the event stream the application resizes. The second method is when
we resize windows by ourselves. In OS X this happens when a GTK+ resize
grip is used. This resize grip is larger than the Quartz resize grip.
When the resize is started outside the "Quartz area", we have to handle
it by ourselves.
This patch fixes this manual window resizing by ignoring events while we
are in the process of resizing (such that the events actually arrive at
the sendEvent handler of GdkQuartzWindow where this resize is handled).
When the resize has finished we break all grabs such that GDK is not
stuck thinking the cursor is still in the resize window.
When GtkPrinterFunc always returns FALSE, for example when looking for
a non existent printer, if print list is done for all backends or print
backend status is UNAVAILABLE, gtk_enumerate_printers() finishes with an
empty backend list and destroy function is never called. We need to
check the backend list again after calling list_printers_init for all
backends and finish the enumeration if it's empty.
https://bugzilla.gnome.org/show_bug.cgi?id=672125
