Tweak the preedit text we get from IBus (via the compositor) to
match what GtkIMContextSimple produces for Compose sequences now.
This provides a unified experience.
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.
Use the infrastructure already available to look up keys, instead.
This does the right thing and looks up the setting across all
sources.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3680
- 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.
This is useful when clients use subsurfaces independently of GDK.
For example if a client creates a subsurface that covers a GdkWindow
entirely. If this subsurface is opaque, Wayland compositors may not
emit callbacks for the surface of the GdkWindow any more.
Adding the covering subsurface via this new API ensures the
GdkWindow will continue to update in this case.
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
This commit unsubscribes CUPS backend from a DBus
signal in idle when listening for new items on Avahi.
Since GDBus emits gathered signals in idle while
checking whether the signal has been unsubscribed
it could happen that a signal was not processed
because it was removed from hash table of
subscribed signals.
This caused the situation where printers advertised
on Avahi were not listed in CUPS backend sometimes.
We need those signals since this happens when switching
from a general subscription which listens to signals
for all Avahi services to a specific one which listens
to just _ipp._tcp and _ipps._tcp (chicken and egg problem).
This change extends set of Avahi advertised printers which
works with Gtk's CUPS print backend.
It creates a temporary queue (local printer) for each
Avahi printer in CUPS instead of accessing them directly
(via CUPS library).
This makes some printers work which did not work before and
also gives users more options to change in the print dialog.
This also changes naming of printers to be in accordance with CUPS.
It uses '_' instead of '-' and has hostname appended for CUPS remote
printers.
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.
Commit e6209de962 added some checks on TranslationEntry.valid in
order to figure out whether using the new font settings or the
old g-s-d ones. However that's only set in the non-sandboxed case.
This makes sandboxed applications fallback to the old (and also
non-existing with modern g-s-d) settings, possibly resulting in
ugly defaults being picked.
Fix this by also marking TranslationEntry elements as valid when
using the settings portal, precisely those entries that we are able
to read and match with our own table.
