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.
Before this patch, imwayland would assume that text-input enter and leave events follow the general (wl_keyboard) focus, and was unable to handle the situation where they would not be provided at the same time.
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.
According to the XEmbed specification, a window should be created
"elsewhere" and then reparented into the target parent window. Instead,
GTK+ creates the window directly in desired target parent window. This
allows some races to occur.
Another program that does not follow XEmbed is tabbed. XEmbed requires
an _XEMBED_INFO property on the to-be-embedded window, but tabbed does
not check for this property. Thus, as soon as GTK+ creates its window,
tabbed starts managing this window and now GTK+ setting up the window
races with tabbed starting to manage the window.
If tabbed is fast enough to map the window, GTK+ never sees a MapNotify
event, because it did not yet select StructureNotifyMask on its window.
This results in a black window inside of tabbed.
Note that this cannot really be fixed in tabbed, since XEmbed says that
the _XEMBED_INFO property must be already present when the window
appears. Thus, patching tabbed to wait for _XEMBED_INFO to appear is not
something that the spec requires/allows.
Instead, this commit changes GTK+ so that it directly sets the right
event mask when the window is created. This means that there is no more
race between tabbed mapping the window and GTK+ selecting
StructureNotifyMask.
Note that the proper fix would be to do as XEmbed requires: Create the
window elsewhere and then reparent it into the target window. However,
that would require a more invasive patch, so this commit only takes the
"easy approach" of fixing this one race. Hopefully, all the other races
that can occur during window setup are harmless, because the
embedder/socket will hopefully watch for PropertyNotify events as
needed.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/757
See-also: https://github.com/awesomeWM/awesome/issues/2385
Signed-off-by: Uli Schlachter <psychon@znc.in>
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
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/
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
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
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. The conversion between formats happens
at GTK level in GtkClipboard or, if GtkClipboard is not used, with
gtk_target_list_add_image_targets() to announce all supported image
formats, and with gtk_selection_data_set_pixbuf() to convert from
any GdkPixbuf formats to the format requested by the selection, and
with gtk_selection_data_get_pixbuf() to convert from the selection
format to GdkPixbuf, if supported.
GDK simply does not play any role in this. 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 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.
GNOME Shell 3.32 will remove support for the app menu
so we need to move its contents to the primary (hamburger)
menu.
widget-factory already had a primary menu.
The only item in the app menu was About.
https://gitlab.gnome.org/GNOME/Initiatives/issues/4
gtk_entry_event's goal is to detect if a specific event concerns one of the two
entry icons. It can happen that this function is called during initialization
and/or before the entry is realized. In this case the entry icons (and the
event) will not yet have an associated window. The code should consider the
aforementioned situation and avoid matching a icon and an event with no
associated windows.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1366
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.
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.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT).
Windows defines deltas inversed for vertical direction
(positive values mean the wheel was turned forward)
but not for horizontal direction
(positive values mean the wheel was turned towards the right).
This commit fixes behavior as both axes were inverted previously.
