| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and use 150 as natural-width.
Currently there's no way for a GtkEntry to be less
than 150px wide (apart from using "width-chars" property),
this is too much for a default minimum-width, an app
developer may need to have a shorter GtkEntry, for example
when the UI it's been shrunk by the user (see [1]) or when
you want to match the size of another widget (which is less
than 150px) see [2] for Evince bug on using
gtk_combo_box_new_with_model_and_entry() for PDF forms where
GtkEntry of ComboBox is too wide and doesn't match the combo
list width.
Using "width-chars" is not a proper solution for these
cases as you may not know how short your GtkEntry will be
or the fact that using "chars" as a width size unit is not
pixel accurate.
Curious note: the commit that introduced the GtkEntry
minimum-width to be 150px is from 20 years ago, see
https://bit.ly/2ySEfK4
[1] This change was already suggested by Benjamin Otte
in a blog comment https://bit.ly/2J96wRo
[2] Fixes issue evince#1002
|
| |\
| |
| |
| |
| | |
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
|
| |\
| |
| |
| |
| |
| |
| | |
into 'gtk-3-24'
Tooltip: Fix the used cursor size if 0 in Settings
See merge request GNOME/gtk!374
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
'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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There is no reason why we shouldn't pass this flag every time
Z-order changes. We have separate routines that are used to
maintain relative Z-order, so it should be completely OK to
pass SWP_NOOWNERZORDER to let the OS know that it shouldn't try
to maintain relative Z-order of the windows when raising them.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Pass SWP_NOOWNERZORDER when rising TEMP surfaces to the top. This ensures that
they don't drag anything else to the top with them. The use-case for this is
a tooltip (which must be on top) appearing for a non-foreground surface,
causing said surface to rise above other surfaces, some of which may
be foreground at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=784766
Fixes issue #852
|
| | | | |
| | | |
| | | |
| | | | |
https://gitlab.gnome.org/GNOME/gtk/issues/1398
|
| | | | |
| | | |
| | | |
| | | | |
Commit 955aa8d54b1ef6b9252e06b19d1d42a971c2b409 forgot this, again.
|
| | |/ /
|/| |
| | |
| | | |
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
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
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
|
| | | |
| | |
| | | |
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.
|
| |/ /
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
GDK W32: send both smooth and discrete scrolling events
See merge request GNOME/gtk!335
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Commit 359df028be7b1dae76a1abb9bad8a3b86a648765 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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Commit 359df028be7b1dae76a1abb9bad8a3b86a648765 changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT). Change it again, to send
both the GDK_SCROLL_SMOOTH and the GDK_SCROLL_(UP|DOWN|LEFT|RIGHT)
event separately (with the discrete event marked as emulated),
as this is what other backends (such as wayland) do.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
imwayland: Don't reset serial while text-input is alive
See merge request GNOME/gtk!339
|
| |/ / /
| | |
| | |
| | | |
The serial number is a persistent property of the text-input object.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
We document this argument as nullable, so treat it as such.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1327
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1325
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
modules: Check current context before retrieving surrounding
See merge request GNOME/gtk!326
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There may be situations where this might get called while the
currently focused context just went away (eg. after setting the
text widget unsensitive).
Closes: #1317
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
imwayland: Fix clearing of preedit text
See merge request GNOME/gtk!329
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes webkitgtk misbehaviour as outlined in https://gitlab.gnome.org/GNOME/gtk/issues/1316#note_312942 , which was introduced in 49b17e6c.
The preedit will be cleared on exit only if it is already present.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes terminal emulator misbehaviour as outlined in https://gitlab.gnome.org/GNOME/gtk/issues/1316, which was introduced in 49b17e6c. The original commit cleared preedit text by setting it to an empty string, which still counted as existing preedit. The fix sets preedit string to null, which is correctly understood as not present.
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | | |
gtk-3-24: build: Raise glib dependency for unicode 10.0 script names
See merge request GNOME/gtk!336
|
