Update our compose sequences based on the current
update xorg Compose.pre file. Beyond that, remove
some deadkey sequences that we are now handling
(better) in code.
Make this script parse gtk-compose-remove.txt for
sequences to remove from the xorg Compose file.
This will be used for removing some deadkey combinations
that we can handle better in code.
Also, make this script explicitly python2. I tried
porting it to python3, but gave up in the end.
For sequences like ``, we want to commit the first
deadkey and then continue preedit with the second.
The alternative is to do chained deadkeys, where
entering ~~a yields ̃̀̃̃a. But we don't do that, and
I think that would be more controversial.
because filesystem readdir order is indeterministic.
Without this patch, building openSUSE's balsa package
had variations between builds in /usr/share/balsa/icon-theme.cache
(cherry picked from commit b364827a5b)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
This can happen whenever the ::activate-link handler sets different
markup on the label, causing all links to be recreated. In this case,
the GtkLabelLink* passed to emit_activate_link is garbage after the
g_signal_emit call and we shouldn't try to do anything with it.
Fixes#1498
56f6ac5f introduced a 20px shadow for the '.tiled decoration:backdrop'
selector. This selector is more specific than the '.ssd decoration'
selector and caused unfocused tiled SSD windows to have a shadow that
focused ones did not have. The mutter code however assumes that the size
of the decoration does not change between the states and this was
causing a crash when clicking below the titlebar in unfocused tiled SSD
windows.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3716
It turns out that we we were sometimes emitting
preedit-end multiple times, and sometimes not at
all. Same for preedit-start. To fix this up, introduce
a in_compose_sequence flag, maintain it, and use it
in the right places.
After these changes, both
C-S-u 1 2 3 Enter
Compose a e
generate the right signals:
preedit-start, preedit-changed,..., preedit-end, commit
Don't warn about Compose file constructs we don't
support. We haven't supported these for a long time,
and nobody has every complained. No need to wake
up sleeping dogs.
Tweak the preedit display for Compose sequences to
be not so distracting. We only show the Compose key
when it occurs in the middle of the sequence or is
the only key so far, and use · instead of ⎄ for it.
Also, make sure to display dead keys more adequately.
- window resizing control area is implemented as where the shadows are drawn
- create a 'fake' shadow for the tiled case to allow easier resizing of
the tiled window ratio even if it's offset to the side of the border
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3670
X11 allows keysyms to be specified in addition to strings.
We only support the strings. In the past, we ignored everything
after the string. Go back to doing that, but issue a warning
that we've ignored the keysym.
These shadows cause a significant draw performance drop for maximized
windows. Disabling them increases the chances we can have faster scroll
performance of text.
There is some risk here for systems where they have a dock and you expect
the shadow to draw beneath that dock for transparency reasons.
Improve compose sequence handling:
- Show preedit for compose seqences
- Support sequences of up to 20 code points
- Warn when ignoring Compose file features
- Support compose sequences producing multiple characters
- Support hex escapes
As the program executable name has 'update' in its filename,
gtk-update-icon-cache.exe is considered to be an installer program on 32-bit
Windows [1], which will cause the program to fail to run unless it is running
with elevated privileges (i.e. UAC).
Avoid this situation by embedding a manifest file into the final executable
that tells Windows that this is not a program that requires elevation.
Also make the autotools build files dist the new script and use the new script
to generate the manifest and rc files, instead of hardcoding the generating
bits in gtk/Makefile.am
Fixes issue #3632.
[1]: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc709628(v=ws.10)?redirectedfrom=MSDN,
under section "Installer Detection Technology"
Currently when GTK3 is compiled without G_ENABLE_DEBUG, the inspector
can't be opened with GTK_DEBUG=interactive because it doesn't parse
this env var without G_ENABLE_DEBUG.
Since the inspector is always good to have, this commit now always
parses the GTK_DEBUG env var but only keep the "interactive" flag if
G_ENABLE_DEBUG isn't defined.
fmin() is a function that is introduced with C99/C++11, so check for the
presence of it and provide a simple implementation for it if it does not
exist.
Also update the config.h.win32.in template accordingly, since this
function is provided on Visual Studio 2013 or later.
The size of the cursor depends on either the gtk-cursor-aspect-ratio
GtkSetting or as of the previous commit on the GtkSetting or the
cursor-aspect-ratio style property. GtkTextView was only considering the
style property.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
The gtk-cursor-aspect-ratio GtkSetting was only recently introduced and
replaced the cursor-aspect-ratio style property. This was causing old
configurations that used CSS to modify this property to no longer apply.
This commit introduces a fallback from the GtkSetting to the style
property if the value of the setting is unchanged.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
The gtk-cursor-aspect-ratio property got added as a float property.
However there is no parser for float values from keyfiles which meant
that it could not be changed from settings.ini.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
When the notebook page does not have a label, it should not fallback to
asking its child accessible for extent, since the child might be asking
exactly the converse when it is a socket, thus getting in an infinite
loop. When the page does not have a label, is does not really make sense to
give it an extent anyway.
Fixes atk#18
The $button_fill hack for button.circular is pretty awkward and is
currently broken. Instead of relying on it, allow the button() mixin to
have an additional background-image optionally.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3354
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
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.
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.
