The existing treeview header button border in GTK3 is close to
invisible. The preferred way to find the border for a treeview column
is to hover the mouse near the beginning of the header button text
expecting the default cursor to switch to 'col-resize' cursor. This
works only when all column headers in the view are left aligned. After
adding a few numeric columns to the view, whose headers are right
aligned, it becomes really hard to find the location of the border
between a left aligned and right aligned column header.
This change addresses the issue by using high contrast colors for
borders of treeview header button - in line with the colors used in
Adwaita theme in GTK4.
See merge request GNOME/gtk!2467
There is some bug somewhere where the geometry ends up being correct.
Mutter didn't handle this gracefully, and is to be changed to simply
respect the protocol and error out the client that sends bogus data.
Prepare for this by instead of sending bogus data, complain loudly if it
would happen dropping the invalid geometry on the floor instead of
sending it.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1527
When the level does not include the style, we only
include one face of each family in the list. But we
were just choosing the first face (typically, a light
or extra-light style). Improve this by picking the
default face (normally, the regular face), which is
the expected behavior.
When setting a window's background to ParentRelative on X11, the window
depths must match to avoid a BadMatch error. Query the X server for the
parent window rather that relying on the parent passed to
gtk_window_new() to prevent crashes with reparented windows.
Fixes: #3288
The last event, matching lifting the finger/releasing the mouse button,
is important when there's a large delay between it and the previous events,
as in when performing a movement, stopping, then releasing fingers as
opposed to doing a swipe.
If this event is skipped, doing this will result in kinetic deceleration
matching the previous finger movement, while the expected behavior would
be no deceleration.
See also 97f540622a for a similar fix in
GtkEventControllerScroll.
When GtkApplication starts listening to the screensaver's D-Bus
status, the screensaver-active property is not initialised and
applications making use of the property are out of sync until the
first state change. Any application starting when the screensaver is
active will think it's inactive.
To fix this, we set the property when we first start monitoring the
screensaver.
See https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1091
epoxy_dep cannot be used in a configure time check when it comes from a
subproject. Use variables set in pc file instead.
This requires https://github.com/anholt/libepoxy/pull/231.
Remove all of the selectors. They just set the passthrough anyway so
there's not much point to maintaining them and they weren't the
complete set of possible selectors.
While it’s true that you can pass the results of
`gtk_file_chooser_get_filename()` straight to `open()` or `fopen()` on
Linux, you can’t do so on Windows as it expects the filename to be in
the ANSI codepage. Using the GLib wrappers `g_open()`/`g_fopen()`
instead means that the appropriate UTF-8 → UTF-16 → `wopen()`/`wfopen()`
conversions are done.
Spotted by Fabian Keßler in
https://gitlab.gnome.org/GNOME/glib/-/issues/2212.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When a plug is embedded in a socket, we need to also plug the at-spi
tree, so that screen readers can find the at-spi content of the plugged
widgets.
This change does this plugging automatically: on the plug widget, an
additional _XEMBED_AT_SPI_PATH property is set to provide the at-spi path
(just like we have _XEMBED_INFO for other X11 information), and when
embedding it, the socket reads it, and makes it as its only child.
Since GtkPlugAccessible can not inherit both from AtkPlug (a child of
AtkObject) and from GtkContainerAccessible (a child of AtkObject), we
actually make GtkPlugAccessible a child of an AtkPlug, and that's what
will be embedded (in at-spi terms) into an AtkSocket.
Similarly, GtkSocketAccessible can not inherit both from AtkSocket and
GtkContainerAccessible, so we make it a parent of the AtkSocket that
embeds the AtkPlug.
This change depends on atk 2.35.1 which implements the at-spi technical
details.
This separates out atk-bridge-2.0 dependency, which is not part of atk,
but of at-spi2-atk.
At least from GTK v3.22.30, the code disallows attempts to print PDF and
PS files using the LPR backend. Although it is not easy or possible for
GTK to determine if the printer can print these formats by querying lpr,
the print backend should allow lpr to try.
There are two uses cases:
- A filter is being used by lpr, specified in the printcap file, to process the
files prior to printing them.
- The printer can print PDF and PS files directly. There are many printers that
can print these formats, so GTK should allow for the possibility.
This implementation is based on gtk_text_view_scroll_to_iter() and
thus shares its limitations for the sake of simplicity.
A single offset is opportunistically picked to build the iterator
needed for gtk_text_view_scroll_to_iter(). That means that substrings
spanning over multiple lines or larger than the current window might
not be displayed optimally after scrolling.
Partially closes#1625, the toPoint() variant has been discarded.
_gtk_settings_get_style_cascade() checks for the given GtkSettings to be
non-NULL, but does so after using the pointer to get the
GtkSettingsPrivate.
Make sure we use the GtkSettings pointer only after the precondition is
verified.
https://gitlab.gnome.org/GNOME/gtk/-/issues/2780
