| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
We do this all the time when moving the cursor and we can now do it
without the GList allocations.
|
|
|
|
|
| |
This is handy whenever we do some operation on all parent widgets of a
widget.
|
|
|
|
| |
Both queue_allocate and queue_resize already queue a draw.
|
|
|
|
|
| |
We don't need to ever invalidate the picture size if the paintable tells
us its size is static. Same for the contents.
|
| |
|
| |
|
|
|
|
| |
@error is (transfer full). So the error passed should be freed if not used
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
I wonder who forgot that.
Whoops.
|
|
|
|
| |
Just ignore all further ones.
|
|
|
|
| |
Typo right there.
|
| |
|
|
|
|
|
| |
instead of being inconsistent and not using them later, which leaves a
bunch of single letters floating among real words, not the prettiest.
|
|
|
|
|
|
| |
* 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
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Extraneous chunk from 7601bca7587dd29bde3d1554e644a10ae6dafc18.
Cherry picked from gtk-3-24, which has a gtk_widget_show_all() function.
|
|\
| |
| |
| |
| | |
A11y: Add support for AtkTableCell
See merge request GNOME/gtk!411
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| |
| | |
icontheme: Recolor <polygon> elements in SVGs too
See merge request GNOME/gtk!443
|
| |
| |
| |
| | |
Otherwise, it's possible to have a symbolic icon where some of the
shapes keep the #bebebe chroma key color.
|
|\ \
| | |
| | |
| | |
| | | |
demos/gtk-demo/combobox: fix typo
See merge request GNOME/gtk!444
|
| | |
| | |
| | |
| | | |
Fix typo that prevented the P-S submenu from displaying correctly
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
GDK W32: Be honest about supported clipboard formats (GTK4)
See merge request GNOME/gtk!399
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Do not lie to W32 about the formats that we provide or accept.
Originally the logic behind such lies was that GdkPixbuf allows us to
convert any supported image to BMP or PNG, and therefore we should
announce that we always provide/accept BMP and PNG along with other
formats.
But that's not how it works. GDK has built-in serializers and
deserializers for all pixbuf formats (where it just invokes GdkPixbuf
API) and will use them automatically to read or write GdkTexture
objects (internally wrapping GdkPixbuf objects where necessary). The
encoding and decoding of images is handled
by GdkContent(De)Serializers, backend has nothing to do with it.
Therefore W32 GDK backend should only offer formats that it can
actually do conversion for by itself (such as image/bmp <-> CF_DIB,
or text/uri-list <-> CFSTR_SHELLIDLIST).
|
| | | |
| | | |
| | | |
| | | | |
This reverts all GNOME 3.32 styling from master
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 9e686d1fb5cb20 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)
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
setting. See #1408
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
|
| |
| |
| |
| | |
Menus should also be deactivated on right-button clicks.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
- for the previous patch
|
|\ \
| | |
| | |
| | |
| | | |
Adwaita GTK Theme: Add bigger shadow and border-radius to menus
See merge request GNOME/gtk!432
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Increase the visibility of the box-shadow for menus
Introduce a border-radius variable for menus
Use this variable for all corners of menus except top for the top menus
|
| | |
| | |
| | |
| | |
| | | |
- tone down the button z-depth
- flatter headerbars
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Issue #1495 showed that the docs of GtkGrid retain outdated implications
that (as was once, but is no longer, the case) it is intended to replace
GtkBox, by discussing HfW and widget properties in a way that suggests
GtkBox can't handle them. But of course it does, and it's preferable for
simple single-row/column cases. Worse, we said GtkGrid “provides exactly
the same functionality” for the latter case, but the original point of
that Issues was that it doesn’t, at least for CSS positional selectors!
Box:
• Use an actually meaningful @Short_description.
• Remove unhelpful @See_also references to unrelated containers.
• Remove references to “rectangular area”: it might be another shape
via CSS, or “rectangular” might falsely imply 2 dimensions of children.
• Mention Orientable:orientation.
• Emphasise usefulness of :[hv]align for allocating in the other axis.
• Don’t say that Grid “provides exactly the same functionality” for a
single row or column, since (A) it is overkill for that case and (B)
said Issue proved that it *doesn’t* for CSS child order, for example.
Grid:
• Don’t dwell on widget properties and height-for-width in a way that
wrongly implies that Box can’t handle those (or Grid can better). In
fact, just get rid of that bit altogether: Box handles them fine, and
such wording was only needed years ago for migration from GTK+ 2 to 3.
• Point to GtkBox as being preferred for the simple row/column use case.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
widget-factory: move app menu contents to primary menu (gtk4)
Closes #916
See merge request GNOME/gtk!365
|
| | | |
| | | |
| | | |
| | | | |
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/916
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This follows the recommendation in
https://gitlab.gnome.org/GNOME/Initiatives/wikis/App-Menu-Retirement
|