If the child is not (partly) revealed, don’t allocate it, or we spam the
console with warnings about giving negative width to children’s gadgets.
We can check :child-visible, which is FALSE if (current&target)_pos == 0
Close https://gitlab.gnome.org/GNOME/gtk/issues/1057
Tools on the same physical item have the same serial number, so the eraser
and the pen part of a single pen share that serial number. With the current
lookup code, we'll always return whichever tool comes first into proximity.
Change the code to use the hw id in addition to the serial number, this way we
can differ between two tools.
Generic tools (Bamboo, built-in tablets) always have the same serial number
assigned by the wacom driver. This includes the touch tool when the wacom
driver handles the touch evdev node (common where users require the wacom
gestures to work).
When the first device is the touch device, a tool is created with that serial.
All future tools now return the touch tool on lookup since they all share the
same serial number. Worse, this happens *across* devices, so the pen
event node gets assigned the touch tool because they all have the same serial.
Since we don't actually care about the touch as a tool, let's skip any unknown
tool. This captures pads as well.
Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
a property that exports the tool type as one of stylus, eraser, cursor, pad or
touch. Only three of those are useful here but that's better than having all
of them as unknown.
* We don't output spaces anywhere in the code, unlike the doc suggested.
* CSS explicitly forbids whitespace between function names and lparens:
https://stackoverflow.com/questions/13877198
We need to call g_strdup() on the name that we pass in for notifying the
GDK_SETTING event so that when we do gdk_event_free() later we will not
get a crash (stack corruption) that results from attempting to g_free()
something that is not dynamically allocated.
and convertPointFromScreen:, making them handle all MacOS versions
so that all of the if-deffing happens in the function definitions.
This happens to fix issue 1518 because it turns out that contrary
to the annotation in the 10.14 nNSWindow.h, convertPointToScreen and
convertPointFromScreen originate in 10.14, not 10.12.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1518
G_GNUC_END_IGNORE_DEPRECATIONS terminates the if statement and does not
consider the following block to be part of the if. So that block was
always taken irregardless of the pattern.
Fixes#1280
We don't want to set ParentRelative when:
- the parent window is NULL
In that case we are unsure about the depth, so better err on the side
of caution and avoid a BadMatch by accepting ugly output.
- the cairo pattern is in an error status
This should never happen - unless you start up in OOM - but better
be safe than sorry.
Might help with the spurious crashes in #1280.
This reverts commit 5aedfe048b.
It had a typo that broke the build, only replaced half of the uses, and
replaced them with other functions that are also deprecated anyway.
Surface returned from gtk_icon_helper_load_surface can be smaller
then requested pixel size. This happens when icon is embedded in
panel that has bigger size then loaded pixbuf.
Fixes#1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
`gtk_widget_accessible_grab_focus()` code checks that X11 isenabled at
build time and uses X11 specific functions such as
`gdk_x11_get_server_time()` regardless of the actual backend being used.
Check that we are using an X11 display when X11 is backend enabled, so
we do not crash when running on Wayland
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
- based on a patch by frederik.feichtmeier <frederik.feichtmeier@gmail.com>
I'm certain this is something we had initially, but can't recall
why we got rid of it for the more visually distracting dashed line.
We can always revert when Lapo shows up and slams us with that broken
use case. I'm guessing non-white bgs.
- So far it looks way less distracting than the dashed line
