I was stuck in an X session and noticed that my resize corners
all got east or north cursors. It turns out that gnome-shell
does not properly advertise support for edge constraints under X11,
and the absence of that makes the code for determining the edge
under the cursor misbehave.
This change should fix that.
So we can check that the currently set clip is the first one and now
intersect with it. This first clip is always the entire viewport or the
entire render_area and we don't want to end up drawing things to a
texture because of it.
g-ir-scanner incorrectly evaluates macro definition that include
references to other macro definitions. Provide a correct value as an
annotation.
Differences in generated gir files:
```diff
@@ -19017 +19017 @@
- <constant name="PRIORITY_REDRAW" value="20" c:type="GDK_PRIORITY_REDRAW">
+ <constant name="PRIORITY_REDRAW" value="120" c:type="GDK_PRIORITY_REDRAW">
@@ -74229,3 +74229,3 @@
</constant>
- <constant name="PRIORITY_RESIZE" value="10" c:type="GTK_PRIORITY_RESIZE">
+ <constant name="PRIORITY_RESIZE" value="110" c:type="GTK_PRIORITY_RESIZE">
<doc xml:space="preserve">Use this priority for functionality related to size allocation.
@@ -106786,3 +106786,3 @@
<constant name="TEXT_VIEW_PRIORITY_VALIDATE"
- value="5"
+ value="125"
c:type="GTK_TEXT_VIEW_PRIORITY_VALIDATE">
```
See !472
If the revealer is told do animate and then unrealize itself, we do
(correctly) stop the animation, but used to do a shortcut where we
just set the target state as current.
Other things are dependent on the animation properly finishing though,
like the contained widget child visibility. This may lead to inconsistent
state where gtk_revealer_get_child_revealed() returns TRUE but the child
widget is unmapped, or vice-versa.
Fully finish the animation here, so the child state is coherent the next
time the revealer is mapped. We can also skip notifying on the property
since it will be handled by gtk_revealer_set_position().
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 display a list of supported protocols in the server_addresses_popover.
However, this curated list contains protocols which may or may not be
available, depending on the respective gvfs backend being installed.
So, populate the list only with protocols which are available.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
When the user types an address with a schema that is not supported,
the Connect button doesn't become sensitive, but there is no visible
feedback at all.
This feels unresponsive and leaves the user clueless.
While it doesn't help explain why the address doesn't work, this will
provide a hint that the input was acknowledged but doesn't work.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
This makes apps use "Segoe UI 9" by default instead of whatever matches "Sans 10".
It also cleans up the code and uses some new pango API while at it.
This was previously disabled in 9e686d1fb5 because it led to a poor glyph coverage
on certain versions of Windows which don't default to "Segoe UI 9" (Chinese, Korean, ..)
because the font fallback list was missing in pango.
This is about to get fixed in https://gitlab.gnome.org/GNOME/pango/merge_requests/34
so enable it again when we detect a new enough pango version.
(See !436 for the original MR)
GTK widgets expect the scroll deltas to be 1 or -1 and calculate a scroll value from that.
Multiplying the delta by the Windows scroll line setting (which defaults to 3) results
in a much larger delta and vastly different behaviour for running a GTK app on Windows
vs on Linux. For example text view and tree view scroll by 9 lines per scroll wheel tick
per default this way while on Linux it is around 3.
Remove the multiplication for now.
See !426 for the gtk3 MR
Enables hinting, antialiasing and set the subpixel orientation according to the
active clear type setting. This ensures that font rendering with the fontconfig backend
looks similar to the win32 backend, at least with the default system font.
See !437
