GitLab

The various strings (pending/current preedit, surrounding, and commit
buffer) are being leaked in the case of GtkIMContext destruction.

    - Selection mode does not get the special devel styling.

    - removed teh last-child() selector for it doesn't work anymore.
      Better style all section of the headerbar than none. Proper fix pending.

By returning a default surface. The situation where there's no
currentContext arises when GtkCSS is trying to determine the
layout sizes so no actual display is necessary.

Closes: #1411

Resolve "gtkdnd-quartz crash when realizing a GtkOffscreenWindow"

See merge request GNOME/gtk!145

GtkOffscreenWindow doesn't have a NSView or NSWindow, so return NULL if
passed one of those.

Closes: #379

Tooltip: Fix the used cursor size if 0 in Settings

See merge request GNOME/gtk!374

Merge branch '1397-gtknotebook-built-in-popup-menu-listing-tabs-doesn-t-use-tab-label-text-for-the-last-tab' into 'gtk-3-24'

Notebook: Ensure menu label updates with tab_label

See merge request GNOME/gtk!385

Fix DND info disposal

See merge request GNOME/gtk!390

Commit 1c96b703 changed the way icon
information is given to DnD. Previously an icon helper was kept at
the drag source site. Now an image definition is stored there.
The difference is that icon helper is an object that changes its
state in response to an icon being set, thus the object survived
multiple icon changes. Whereas image definition is destroyed and
re-created from scratch every time a drag icon is changed.
This created a problem where gtk_drag_begin_internal() would receive
the value of site->image_def when a drag just began, then it emits
"drag-begin" signal, in response to which an application can
set drag icon, changing the value of site->image_def. However,
gtk_drag_begin_internal() is unable to know about that change and
continues to use the old value it received from up the stack.

Not only does it prevent drag icon from being set from "drag-begin",
it also can induce a crash, since the old image_def value used
by gtk_drag_begin_internal() points to a freed memory region.

Fix this by only setting a default icon (which is created in-place)
in gtk_drag_begin_internal() if the caller does not care about icons.
Otherwise gtk_drag_begin_internal() will return a boolean that indicates
whether an icon needs to be set. Then the caller can invoke
gtk_drag_set_icon_definition() to set the icon, if needed.

Fixes #1407.

gtk_drag_clear_source_info() immediately unrefs the info attached
to the context (the very same info we're in the process of destroying
in gtk_drag_source_info_free()). If that reference was the last one,
then accessing the info object after that is a use-after-free error.
Also, change the order a bit to first free the event, and only then
unref the context.

Fix this by copying all the fields of the info that we need, and
then working with these copies.

Don't let the OS maintain relative Z-order for windows

See merge request GNOME/gtk!196

https://gitlab.gnome.org/GNOME/gtk/issues/1398

Commit 955aa8d5 forgot this, again.

This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
buildable_add_child() calls set_tab_label(), but the latter did nothing
to update the menu_label corresponding to that tab with the new text.
Using Builder to populate the tab child, only tabs other than last got
the right non-default labels, and even that was mostly coincidental, as
adding the main child called update_labels() via real_insert_page(), so
it took effect when the 2nd last main child is added, updating the rest
but leaving the last with the default label, not that given in Builder.

Fix by factoring out the code from child_reordered() to a new helper
menu_item_recreate() and calling that in set_tab_label(), so that
whenever the tab_label is updated, so is its corresponding menu_label.

This fixes the reported case and presumably others that we could write.

fixes https://gitlab.gnome.org/GNOME/gtk/issues/1397

It calls set_tab_label(), which already does that.

Comments matched to reassure the compiler that fallthrough is
intentional are supposed to precede the case or default keywords, at
least in GCC, so the one here did not suppress the warning with GCC. We
can just the if condition and put the comment at the end to solve that.

https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/

quartz: do not cache the screen in the gdkmonitor

See merge request GNOME/gtk!375

Instead we just cache the monitor number and get
out of it the nsscreen when it is needed. This is
a requirement since it nsscreen it is not supposed
to be cached.

Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1312

- nightly apps get a headerbar styling

gtkimcontextime.c: Fix Korean input

See merge request GNOME/gtk!356

Commit c255ba68 inadvertently introduced a regression that broke Korean
text input because the changes there resulted that only the last input
string that we have from ImmGetCompositionStringW() for each time the
commit signal is emitted is kept, and also as a result the final Korean
character that is input by hitting space is also lost as a result, as we
didn't check for whether we are done with preediting.

Fix these issues by doing the following when we receive the
WM_IME_COMPOSITION message with GCS_RESULTSTR from Windows:
-Do not emit the commit signal during WM_IME_ENDCOMPOSITION, and...
-Emit the commit signal anyways, as we did before, c255ba68, however...
-We still save up the string to commit, because we need to re-compute
 the cursor position when we do ->get_preedit_string(), which needs to
 take the GCS_RESULTSTR string we get from WM_IME_COMPOSITION into
 account as well, so that we avoid getting the Pango criticals that
 occur during Chinese (and most likely Japanese) input as the cursor
 position is out-of-range.

Fixes issue #1350.

The gtk_stack_snapshot_slide() function dereferences the
last_visible_child pointer without proper != NULL ckeck. This might
result in NULL pointer dereference and crash if last_visible_child is
invalid.

Add a != NULL check before dereferencing the pointer.

cherry-picked from https://gitlab.gnome.org/GNOME/gtk/merge_requests/361

Before the recent rework of positioning in GtkTooltip, the widget always
used the cursor_size of the GdkDisplay. That work redid this to instead
take GtkSettings::gtk-cursor-theme-size. But that property's doc says:

> Size to use for cursors, or 0 to use the default size.

and has 0 as its default. This is quite a likely scenario for anyone
whose desktop or settings.ini does not explicitly provide a cursor size,
which is the case for XFCE and win32, to name just two common platforms.

Then, it seems getting a cursor_size of 0 causes GtkTooltip to freak out
and hide/show itself at a very rapid speed, thus making it unusable.

So, we should check whether the Settings return 0 and, if so, still use
gdk_display_get_default_cursor_size (display) to ensure we get a size.

https://gitlab.gnome.org/GNOME/gtk/issues/1371

GDK W32: Support switching input modules at runtime

See merge request GNOME/gtk!366

This leverages the normal input module switching mechanism in GTK
by making it think that the gtk-im-module setting changed.
The backend returns gtk-im-module value as "ime" if W32
IME API says that an IME is in use. Otherwise it returns
and empty string - this still triggers an input module
loading code, which, not being able to load the desired module
(which is and empty string), falls back to looking at current
keyboard layout.

Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of loading appropriate
input modules at runtime. At least, the kinds of modules that specify
languages for which they are loaded automatically by default, and the
IME module.

Loading other kinds of input modules might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of loading the IME input module that is used
for Korean, Chinese and Japanese (and some other languages).

Until someone figures out a way to actually change gtk-im-module
setting on Windows at runtime with meaningful values, the behaviour
introduced by this commit seems like a sufficient workaround.

There's not much we can do about the signal not being handled, but
we should fetch the return value anyway.

Suggested by Garnacho. Hopefully fixes #1349.

Note: I'm riskily committing this via web UI not because I'm lazy
(though I am :) but because I'm seeing a weird host key when I try to
push or pull from GitLab.

Make dashed border-style work correctly

See merge request GNOME/gtk!349

All the other conditionally visible child widgets have this. Without it,
it seems some cases can wrongly reveal it, with a nonsensical home icon.

https://gitlab.gnome.org/GNOME/gtk/issues/1345

There’s a short-path done for focus rectangles, but it can be taken in other conditions, and then fail occasionally to render a dashed line if the border-width is too big.