So dialogs, pop-ups, etc. behave as expected when parent is in
full-screen.
Tiling is allowed for normal windows and splash screens and disallowed
for others.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1627
In case the theme doesn't set a height/min-height for the treeview
separator the treeview drawing gets confused and draws rows on top of each
other depending on the redraw area.
This is due to gtk_tree_view_get_row_height() assuming that a node with a
height <= 0 is not set and not a separator and it will default to the
expander size.
Ideally gtk_tree_view_get_row_height() would know if it operates on a separator,
but there are too many calls/levels, so just make sure the separator height
is at least 1 (Adwaita already sets "min-height: 2px", so no change there)
GtkMenu's "accel-group" property setter, gtk_menu_set_accel_group(),
currently returns in failure if the caller passes it a NULL `accel_group`
argument. This argument is annotated with `(allow-none)`. This patch
add support for the NULL case.
When 0 or GDK_CURRENT_TIME is passed to gtk_window_present_with_time(),
print a warning so that the application developer knows that this isn't
a supported use of the function, but carry on working for now.
We now need to link to fribidi.lib explicitly in both GDK and GTK.
Since the Pango we require in 3.24.x already requires a FriBidi
installation, the .lib and DLL should already be available for the
build.
If the column used for the GtkTreeView:tooltip-column contains NULL
we're already skipping a tooltip; let's ignore empty strings as well,
as an empty tooltip is pretty much pointless.
Close#1681
We're using [a-z] ranges with sed and grep, and POSIX does not specify
their behaviour in non-ASCII locales:
In the POSIX locale, a range expression represents the set of
collating elements that fall between two elements in the collation
sequence, inclusive. In other locales, a range expression has
unspecified behavior
-- IEEE Std 1003.1-2017, § 9.3.5 (7)
This can lead to no results, or invalid replacements, which in turn can
lead to broken builds or broken build artifacts.
Fixes: #1662
Specifically it is avoided to be toggled if:
- Just received focus (in order to preserve OSK state across focus changes)
- Moving cursor around. Still allow some jitter as perfect accuracy is not
possible.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1277
When we receive a size from the move-to-rect implementation, force GTK
to continue using that size until reconfigured by move-to-rect, or
when remapped.
Fixes: #1651
On X11, the position of the menu is calculated synchronously by
gdk_window_move_to_rect(). This means that calculating the window size
when showing is too late, as that'd mean the size used when calculating
the position is out-of-date. The first time a menu is mapped, however,
the size is calculated during realization; but a window is only realized
once, so it doesn't work for subsequent maps.
Currently, this is harmless, as a GtkMenu can change its size however it
wants after it has been mapped. This, however, is problematic, as it
means the position calculated by gdk_window_move_to_rect() might no
longer be valid, or constraints made by the same function might no
longer be respected.
Thus, this is a preparation for making GtkMenu popups stay the same size
until they are remapped again at a later point.
