We already support binding properties; by adding new attributes to the
`property` element we can automatically call g_settings_bind() on the
object ourselves.
We need to invalidate the Pango contexts when
font settings change. Use the new helper
gtk_widget_update_pango_context to make it less
likely that we forget to update some things.
The cairo_t that we create to render glyphs for
the glyph cache needs to match the font options
that are supposedly governing how glyphs are
drawn.
Since we allow font options to be different per
widget in gtk, we need to have them at least at
the level of individual render nodes. Adding them
to the lookup key for the glyph cache has the
side effect of solving another problem: We are
not flushing the cache when font options change.
Since font options affect how the glyphs get rendered,
we need to pass the font options down from the gtk level
to where the glyph cache is populated.
Add a new gsk_text_node_new_full api that takes a
cairo_font_options_t in addition to the other parameters.
If the alpha channel is zero, it doesn't matter what the values of the
red, green and blue channels are: the pixel is still fully transparent.
On most architectures, fully transparent pixels end up all-zeroes
(fully transparent black), matching what's in the reference PNG file;
but on mips*el the blend-difference and blend-normal tests get all-ones
(fully transparent white) and a test failure.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/4227
Signed-off-by: Simon McVittie <smcv@debian.org>
This lets people switch back to font rendering that is closer
to what GTK 3 does. It is not perfect - subpixel antialiasing
is not going to work. But it give us an Escape hatch while
we shake out the bugs in our linear layout.
Related: #3787
Make it clear that your class must have all the editable properties
already before you call the (confusingly named) function
gtk_editable_install_properties.
This adds support for sequences like <Compose>,G,u -> capital G with
breve. Previously, only a capital U was accepted for E, G, I and O
(but a lower-case u was accepted for A and U for some reason).
Signed-off-by: Simon McVittie <smcv@debian.org>
The GtkComposeTable cache is always in big-endian format and is
byteswapped on load for the more common little-endian CPUs, but
init_builtin_table() in GtkIMContextSimple can't byteswap the built-in
data without copying it, which is undesirable. Pregenerate both big-
and little-endian compose data, and compile the correct flavour into
each build of GTK. This fixes failure of the composetable test when
building for a big-endian architecture such as s390x and (traditional,
big-endian) powerpc.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/4217
Signed-off-by: Simon McVittie <smcv@debian.org>
Dragging will just drag the render node.
Dropping will replace the current contents of the textview with the
dropped node.
Neat side effect: You can drag the node onto itself to do a
deserialize/serialize of the current text.
This is needed as GskRenderNode is its own fundamental type and has its
own GValue infrastructure. And I want to put render nodes into the
clipboard which uses GValues.
It seems these are sent with `xwindow` set to the root window, so this
was failing to find a surface and get the screen from that.
I'm not sure if there's a reason not to get the screen this way
elsewhere in the function, but it seems this should be correct.
This fixes the behavior of `gdk_x11_display_get_monitors()`, which
wasn't correctly changing when monitors were added or removed. For
instance, this python code was always showing the same number of
monitors when one was turned off and on, but updates correctly with this
change applied:
```python
import gi
gi.require_version("GLib", "2.0")
gi.require_version("Gdk", "4.0")
gi.require_version("Gtk", "4.0")
from gi.repository import GLib, Gdk, Gtk
def f():
print(len(Gdk.Display.get_default().get_monitors()))
return True
GLib.timeout_add_seconds(1, f)
GLib.MainLoop().run()
```
The clang build fails due to -Werror=implicit-fallthrough being
on by default and some fallthrough cases not being marked as such.
Use G_GNUC_FALLTHROUGH or duplicate the code in those cases.
Claim the pressed, released and canceled gestures
meant for the expander-icon of the TreeExpander.
This avoids selecting the row when expanding or collapsing it.
Closes#4199
The installed ITS rule filename is "gtk4builder.its". The .loc file
is wrongly pointing to old "gtkbuilder.its" which makes gettext fail
on systems without GTK3 installed.
_gdk_macos_event_source_new() calls g_source_set_static_name(), which
for GLib versions before 2.69.1 is a macro defined in gdk-private.h.
Fixes#4195
modified: gdk/macos/gdkmacoseventsource.c
Goals:
1. Provide as much information as possible in the error message, so
users can try to fix their system themselves.
2. Try to formulate the error message in a way that explains that this
is not something GTK can fix, but a lower layer problem.
Related: #4193
We can use the new binding helpers to make this
a little less bothersome. That way, it will need
tweaks less often (only when new fundamental types
are introduced).
The child of a GtkExpander is owned directly by the expander whenever
the "expanded" flag is unset.
We are adding an additional reference to the child of an expander when
expander is not expanded.
Additionally, if a GtkExpander is disposed while not expanded, we need
to explicitly release the reference on the child widget that we own.
This reference leak was masked in GTK3 by GtkContainer removing each
child from the parent container by recursively calling
gtk_widget_destroy().
This gesture is set on the whole widget surface, since there's
multiple input targets inside an entry (icons, the GtkText itself)
it makes sense to consider the full entry an area handling clicks.
Ensure these events don't propagate further up, and result in other
actions.
The default theme changed from Adwaita to Default and this tripped up
the logic to detect if the tarball builds contain pre-built css files or
not. Fix this by looking at pre-compiled css files in themes/Default/
instead of themes/Adwaita/.
This gesture is set on the whole widget surface, since there's
multiple input targets inside an entry (icons, the GtkText itself)
it makes sense to consider the full entry an area handling clicks.
Ensure these events don't propagate further up, and result in other
actions.
This gesture is set on the whole widget surface, since there's
multiple input targets inside an entry (icons, the GtkText itself)
it makes sense to consider the full entry an area handling clicks.
Ensure these events don't propagate further up, and result in other
actions.
All possible ramifications after button1 press (move cursor,
begin drag, begin dnd, select word/line, ...) result in user
actions. The right thing after that is consuming the events,
set the gesture state for that.
The font sizes demo had the space between the font-size spans,
causing us to have a run with just a default sized space between
the words, which in turn leads to wobbly cursor sizes. Avoid that
by including the space in the preceding span.
Also, make it bigger.
Update all the places where we switch over
PangoAttrType to handle PANGO_ATTR_TEXT_TRANSFORM,
and do nothing for now - text-transform support
will land in 4.6.
The old code was just pasting local clipboard data that we put there
ourselves and was causing criticals on remote clipboard data. Now the
code does the proper async paste.
When we initialize OpenGL, check whether we have OpenGL 2.0 or later; if not,
check whether we have the 'GL_ARB_shader_objects' extension, since we must be
able to support shaders if using OpenGL for GTK.
If we don't support shaders, as some Windows graphics drivers do not support
OpenGL adequately, notably older Intel drivers, reject and destroy the GL
context that we created, and so fallback to the Cairo GSK renderer, so that
things continue to run, albeit with an expected warning message that the GL
context cannot be realized.
Also, when we could not make the created dummy WGL context current during
initialization, make sure that we destroy the dummy WGL context as well.
Fixes issue #4165.
With gtkmm, when using `Application()`, the display is initialized
before we know the application name and therefore, the program class
associated to the display is NULL.
Instead of providing a default value, we set it equal to program name
when NULL. Moreover, we give up on capitalizing the class name to keep
the code super simple. Also, not using a capitalized name is
consistent with `gdk_x11_display_open()`. If someone has a good reason
to use a capitalized name, here is how to do it.
```c
class_hint = XAllocClassHint ();
class_hint->res_name = (char *) g_get_prgname ();
if (display_x11->program_class)
{
class_hint->res_class = (char *) g_strdup (display_x11->program_class);
}
else if (class_hint->res_name && class_hint->res_name[0])
{
class_hint->res_class = (char *) g_strdup (class_hint->res_name);
class_hint->res_class[0] = g_ascii_toupper (class_hint->res_class[0]);
}
XSetClassHint (xdisplay, impl->xid, class_hint);
g_free (class_hint->res_class);
XFree (class_hint);
```
Fix eff53c023a ("x11: set a default value for program_class")
It is basically not used by default and is pretty much broken at this point, so
it's about time to drop it.
Let's focus on fixing the OLE2 DnD protocol.
Same thing as the previous popovermenu commit, except for the base popover
because the popovermenu needs special behaviour with e.g. sides arrow so
we need to have the "cycle around" for regular popovers here too.
Currently when moving the focus with (Shift+)Tab, it also traverses the window's
widgets, although it would be expected that the focus stays within the popover,
as it's (almost) like it's a separate window. This would be consistent with
the behaviour of the Up/down arrows, which do cycle around the focus once it
reaches the end.
So this commit makes the popovermenu cycle around focus in any direction, apart
from left/right because they are used to open and close submenus and it wouldn't
make sense anyway to cycle horizontally as there's usually only one widget per
line.
Long time ago, Cairo shadows in both GTK3 and 4 were drawn at a size about
twice their radius. Eventually this was fixed but the shadow extents are
still calculated for the previous size and appear unreasonably large: for
example, 141px for a 50px radius shadow. This can get very noticeable in
places such as invisible window frame which gets included into screenshots.
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3419 just divides the
radius by 2 when drawing a shadow with Cairo, do the same when calculating
extents.
See https://gitlab.gnome.org/GNOME/gtk/-/issues/3841
Our compose table format is still limited to 16bit
values for keysyms, but what we see in key events
can be 32bit values, and we treat them as such now.
Fixes: #4149
It broke keyboard focusing any widget added through the custom widget
menu feature. So for example if you put e.g. a custom check box widget
in a menu, you won't be able to focus it.
This is because the gizmo is mostly used to custom drawing with e.g.
CSS for small visual elements like scale markers. That's probably why
gizmo's default focus overrides block the focus from going through
the children. So this commit fixes it by overriding those and passing
the focus through the children.
Slide animations cause changes in the size requests due to the
behavior of GtkRevealer. We can avoid those by using cross-fades, which
don't have that problem.
Besides, cross-fades look better anyway.
harfbuzz has all the information we need, so we
can avoid poking directly at freetype apis. Also
drop the caching of color glyph information until
it turns out to be a problem.
Instead of havoing a label for the video frame that clashes with the
background of the video, add a frame around the text styles box and add
a label for them. As a side benefit, it also makes it more obvious that
it is scrollable.
Note: Most of this patch is just reindenting.
Currently we update the :active property on both the previous and
new focus button. That "visually activate" the button and will
emit ::toggled, but if the button is associated with an action,
the action state won't change.
Fix that by activating the new focus instead of explicitly fiddling
with the :active property.
Remove the limitation on the number of dead keys
that we match, and allow the result be be multiple
characters.
Regenerate the builtin sequences, since this changes
what dead key sequences we can reproduce algorithmically.
Update tests to match.
Fixes: #10
Make gtk_check_algorithmically take a GString
for the result. This is in preparation for allowing
multi-character results here, in the future.
Update all callers.
Delegating the action to the compositor not only improves consistency
with server-side decorations, but also allows for actions that aren't
available client-side (like lower-in-middle-click).
https://gitlab.gnome.org/GNOME/mutter/-/issues/602
Look who changed his mind since commit 8e2ffb3b46 :-)
The "call" scope means that the callback is only used during the
function call itself (here: gtk_widget_class_install_action()).
That's clearly wrong here, as the callback is invoked every time
the action is activated.
Arguably the "notified" scope is a better match here, where the
lack of a GDestroyNotify parameter suggests that the callback may
be used forever (which is the case here).
Related: #3498
This way, it can be set in GtkBuilder.
Also make sure to only ever look at the GTypes set in the formats, as
GtkDropTarget cannot deal with mime types.
Now, we just print a whitespace-separated list of GTypes and mime types.
This makes this neat for 2 things:
1. Parsing it (see next commit)
2. Using it in GtkBuilder (see commits after that)
In particular, the common case of supporting a single GType (or mime
type) looks like just printing the GType (or mime type), which in
GtkBuilder looks like
<property name="formats">GdkTexture</property>
Usually the "dnd-finished" signal will be used to unref the GdkDrag. In
those cases, we would lose the object, so that when we do the final
drag_drop_done() afterwards, we wouldn't have a remaining reference.
With the reference guard, this now works.
It is good practice for (floating) window managers to respect explicit
position hints from clients (as long as the window wouldn't end up
off-screen etc.).
Before commit 13d3afa56e, GTK had a flag for setting the PPosition hint,
but now does so unconditionally. However the real intention is to *not*
request a fixed position, so don't do that.
Currently we use layout coordinates and widget height when determining
where a click or drag has happened. If the widget has top padding (which it
does inside a GtkEntry, for example), the area where it's possible to select
text is shifted down, so the part of GtkText above the layout is not counted
as the draggable area and instead the equal area below the widget is counted.
Since GtkText is always single-line, there's no need to do any of that and
we can use widget coordinates. Then the draggable area matches the widget
and the problems goes away.
The dummy Win32 window that we use to capture display change events and
to create dummy WGL contexts was created with CS_OWNDC, so we really do
not need to (and should not) call ReleaseDC() on the HDC that we
obtained from it, so drop these calls.
Since the shaders need to be updated for using with GLES (libANGLE at
least), default to WGL for now. Unfortunately it is not that common for
Windows to have GLES support, in which the easiest way to obtain such
support is via Google's libANGLE.
It turns out that the problem of the WGL window not drawing was due to
the fact that I messed up where I placed SwapBuffers() during the
conversion... doh:|
At the same time, stop storing the HDC in the GdkWin32GLContextWGL, but
instead always create it along the surface we created, so that it is ready
for use for operating with WGL when we are not dealing with "surfaceless"
contexts. If we are dealing with "surfaceless" contexts, just use the
HDC of the dummy window that we created when we created the
Gdk(Win32)Display.
WGL contexts should now be in working order at this point.
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
nvidia sets the default draw buffer to GL_NONE if EGL contexts are
initially bound to EGL_NO_SURFACE which is exactly what we are doing. So
bind them to GL_BACK when drawing, as they should be.
See https://phabricator.services.mozilla.com/D118743 for a discussion
about EGL_NO_CONTEXT and draw buffers.
This way, one can force using WGL on Windows even if EGL support was
enabled. Also update the help text for gl-egl as it will apply for
Windows, albeit a bit later.
This has the benefit that we can refactor it and make sure we deal with
GdkDisplay::init_gl() not being called at all because
GDK_DEBUG=gl-disable had been specified.
It's not used there, but both backends have independent
immplementationgs for it.
I want to get rid of GdkGLContextX11 and moving code from it is the
first step.
Now that we have the display's context to hook into, we can use it to
construct other GL contexts and don't need a GdkSurface vfunc anymore.
This has the added benefit that backends can have different GdkGLContext
classes on the display and get new GLContexts generated from them, so
we get multiple GL backend support per GDK backend for free.
I originally wanted to make this a vfunc on GdkGLContextClass, but
it turns out all the abckends would just call g_object_new() anyway.
Instead of
Display::make_gl_context_current()
we now have
GLContext::clear_current()
GLContext::make_current()
This fits better with the backends (we can actually implement
clearCurrent on macOS now) and makes it easier to implement different GL
backends for backends (like EGL/GLX on X11).
We also pass a surfaceless boolean to make_current() so the calling code
can decide if a surface needs to be bound or not, because the backends
were all doing whatever, which was very counterproductive.
The code to create and manage a fake egl surface to bind to is
complex and completely untested because everyone seems to support this
extension.
nvidia and Mesa do support it and according to Mesa devs, adding support
in a new driver is rather simple and Mesa drivers gain that feature
automatically, so all future drivers shoould have it.
... or more exactly: Only use paint contexts with
gdk_cairo_draw_from_gl().
Instead of paint contexts being the only contexts who call swapBuffer(),
any context can be used for this, when it's used with
begin_frame()/end_frame().
This removes 2 features:
1. We no longer need a big sharing hierarchy. All contexts are now
shared with gdk_display_get_gl_context().
2. There is no longer a difference between attached and non-attached
contexts. All contexts work the same way.
Do not treat the context as already current when the value
of context::in-frame changes.
This is so we can bind to EGL_NO_SURFACE if context::in-frame == false
and to context::surface if context::in-frame == true.
This allows getting rid of the attached property in future commits.
The vfunc is called to initialize GL and it returns a "base" context
that GDK then uses as the context all others are shared with. So the GL
context share tree now looks like:
+ context from init_gl
- context1
- context2
...
So this is a flat tree now, the complexity is gone.
The only caveat is that backends now need to create a GL context when
initializing GL so some refactoring was needed.
Two new functions have been added:
* gdk_display_prepare_gl()
This is public API and can be used to ensure that GL has been
initialized or if not, retrieve an error to display (or debug-print).
* gdk_display_get_gl_context()
This is a private function to retrieve the base context from
init_gl(). It replaces gdk_surface_get_shared_data_context().
Create it during init and then reuse it for all contexts.
While doing that, also improve error reporting - that's not used yet but
will in later commits.
This is not used yet, but it allows surfaceless GL contexts.
For that purpose, we need to make the display a construct-only property,
so that it can be set when the surface isn't.
This adds a bunch of very picky checks in the constructor so nothing bad
can happen.
... and move some members from the GdkDisplay struct.
We've always wanted to add one to isolate the display from the backends
a bit more, but so far it's never happened.
Now that I'm about to add more data to GdkDisplay, it's a good excuse to
start.
We try EGL first, but are very picky about what we accept.
If that fails, we try to go with GLX instead.
And if that also fails, we try EGL again, but this time accept anything.
The idea here is that EGL is the preferred method going forward, but GLX is
the tried and tested method that we know works. So if we detect issues with
EGL, we want to avoid using it in favor of GLX.
Also add a GDK_DEBUG=gl-egl option to force EGL at all costs and not try
GLX.
That way, we can give a useful error message when things break down for
users.
These error messages could still be improved in places (like looking at
the actual EGL error codes), but that seemed overkill.
Query the EGL_VISUAL_ID from the egl Config and select a config with the
matching Visual.
This is currently broken on Mesa because it does not expose any RGBA
X Visuals in any EGL config, so we always end up with opaque Windows.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/149
This reverts commit c35a6725b9.
This approach doesn't work because if NVIDIA doesn't work for EGL, the
EGL implementation won't be provided by NVIDIA, so checking the vendor
doesn't work.
Instead, use the display's "leader surface" when no surface is required,
because we have it lying around.
Really, we want to use EGL_NO_SURFACE, but if that's not supported...
Instead of going via GdkVisual, doing a preselection and letting the GL
initialization improve it, let the GL initialization pick an X Visual
directly using X Visual code directly.
The code should select the same visuals as before as it tries to apply
the same logic, but it's a rewrite, so I expect I messed something up.
1. We're using EGL most of the time anyway, so if we wanted to cache
things, we'd need to port it there.
2. Our GL handling is massively configurable, so determining when to use
the cache and when not is a challenge.
3. It makes startup nondeterministic and depend on whether a GTK4 app
has previously been started on this display and nobody thinks about
that when debugging.
4. The only benefit of the caching is delaying GL initialization - which
made sense in GTK3 where almost no app used GL but doesn't make sense
in GTK4 where almost every app uses GL.
So unless I find a big benefit to reintroducing it, this cache will be
gone for good.
Avoids having to use private data, though the benefit is somewhat
limited as we still have to put the destructor in the egl code and can't
just put it in gdk_surface_x11_finalize().
We only have one config, because we use the same Visual everywhere.
Store this config in the GdkDisplayX11 struct for easy access.
Also do this on initialize, because if creating the config fails, we
want to switch to GLX instead of failing to do GL at all.
This also simplifies a lot of code as we can share Visual, Colormap, etc
across surfaces.
There's no need to use g_object_set_data() for it.
We can also stop caching it elsewhere because we know the display has
it.
And finally, we can remove the display->have_egl boolean and use
display->egl_display != NULL instead. We initialize the display at
startup, so that variable is the perfect indicator.
We need to initialize GL to select the Visual we are going to use for
all our Windows.
As the Visual needs to be known before we know if we are even gonna use
GL later, we can't avoid initializing it.
Note that this previously happened, too. It was just hidden behind the
GdkScreen initialization.
We don't want to bind ourselves to GTK3 - both because we don't want to
accidentally cause bugs in a different codebase and because we want to
deviate from it.
While doing so, also store visuals as visuals and not as integers.
And only store one Visual because GTK4 only uses one visual.
And then remove the code that is leftover for dealing with the
compatibility Visual for GTK3.
PS: I'm kinda proud of my STRINGIFY_WITHOUT_BRACKETS hack.
The old code was ordering visuals by depth, but considering that these
days we either use the default visual or a 32bit RGBA visual, that
reordering does not have an effect anymore.
In theory, the only effect is that the GLX Visual selection might select
a different replacement Visual when it checks for improved GL Visuals, but
even there I can't come up with a case where that matters, because
again, the visuals are only reordered by depth and we want to keep the
depth.
In any case, make this a separate commit so bisecting can find this
problem if it ever shows up.
Instead of the display telling the screen to tell the visuals to tell
the display to initialize itself, just init the display directly.
What a concept.
That's a sneaky trick so my edit/compile/test cycle goes faster:
I usually use demos for testing so the tools don't have to be linked for
me to start testing.
If the pointer capability is added, pointer swipe and pinch gestures
will be created. However, if the pointer capability is removed, the
gesture objects won't be destroyed.
If the pointer capability is removed and added several times in a row,
for example due to plugging and unplugging physical mouse, this can lead
to leaking the old gesture objects.
In order to prevent that, this change makes the seat destroy swipe and
pinch gestures when the pointer capability is withdrawn.
It's only used during DND to allow use of the root window's cow window
as a DND target, because apparently gnome-shell used to think that was a
great idea to DND to the overview.
Somebody complain to gnome-shell devs about it not being a good idea if
they want it fixed.
Potentially using Wayland is a better idea though.
This reverts 85ae875dcb
Related: https://bugzilla.gnome.org/show_bug.cgi?id=601731
It's not 2011 anymore, and we shouldn't randomly build one of 10.000
different combinations of X11 backends (I counted the possibilities) but
exactly the one we expect people to use.
Instead, ensure that sassc is made madatory on git builds (because
it is, we don't ship CSS files anymore) and not even looked for in
release builds (because do ship CSS files there).
We don't want people to build Vulkan support when they just want to get
GTK built.
This is in particular true for GTK as a CI subproject or for people
using jhbuild.
Worse, just having Vulkan support compiled in tends to cause crashes
in the Inspector, even if you are not using it.
GTK supports webm playback, which means a backend should always be
compiled.
The ffmpeg backend however is incomplete (no audio) and as such, we
don't want people to end up with it accidentally.
Since we don't want to drag an entire gstreamer build into our ci
on MacOs or msvc, explicitly disable the gstreame media backend there.
Set all settings to their default values, so we
are less dependent on the environment to be set
up just right. In particular, this fixes animations
being disabled when we happen to run in a vm.
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
Scale factors can be negative, but we were not
looking out for that, triggering an assertion when
trying to create a render target with negative
width of height. Avoid that.
Fixes: #4096
Eliding totally transparent content from the node tree is
not 100% correct, since filters can make things visible, so
we need to at least preserve the bounds. We can do that by
creating a transparent color node.
Apply heuristics to avoid breaking users existing configurations
with the change to not always add the default sequences.
If we find a cache that was generated before 4.4, and the Compose
file does not have an include, and doesn't contain so many sequences
that it is probably a copy of the system one, we take steps to keep
things working, and thell the user about it.
All tables use the compact format now, and we generate
caches in that format too. Bump the cache version to 3
for this.
Replace the python script for generating the builtin table
by a small C program using the same code to generate the data
for the builtin table. This drops the restriction on only
generating a single character in the builtin sequences.
When we find a Compose file, replace the builtin
sequences with the table we found. This matches the
semantics described in Compose(5), and makes it possible
to drop unwanted sequences from the builtin table.
It is slight change of behavior for users with existing
Compose files. To match the previous behavior, you have
to add
include "%L"
to your Compose file, to keep the builtin sequences in
addition to your own.
This lets us naturally replace matching sequences
while parsing. That means that the semantics are now
"last one wins" if the parser sees multiple entries
for the same sequence.
Add a testcase that checks the new replacement semantics.
Keep the list of composetables private to GtkIMContextSimple,
and just have an api that creates new GtkComposeTables, either
from a file or from data.
Update tests to use the new api.
This shows how to use a layout manager in a widget,
implemented in javascript. The example sets up the
environment for running from the toplevel dir, assuming
that the build dir is called 'build'.
It apparently worked by chance in the past, but now causes e.g.
alphanumeric characters to be interpreted as half-width katakana
when using the Japanese IME.
We're using the tag contents array to count the number of invisible tags
set but we always increase it without being initialized.
This may lead to unexpected behavior when traversing them and it's
causing a reliable failure in the textiter tests under s390x.
So, memset that area content to 0 once allocated. It's not needed to do
the same for the tags themselves as we always assign them.
Conditional jump or move depends on uninitialised value(s)
at 0x4CFAA00: _gtk_text_btree_char_is_invisible (gtktextbtree.c:2569)
by 0x4B8A1BB: find_visible_by_log_attrs (gtktextiter.c:3244)
by 0x10E93D: check_backward_visible_word_start (textiter.c:484)
by 0x10E93D: test_visible_word_boundaries (textiter.c:523)
by 0x533288F: g_test_run_suite (in /usr/lib/s390x-linux-gnu/libglib-2.0.so.0)
by 0x53328E7: g_test_run (in /usr/lib/s390x-linux-gnu/libglib-2.0.so.0)
by 0x109CC1: main (textiter.c:807)
In many cases, we have an "extra-menu" property that is used to allow
applications to join menus into the native menu for the widget. Previously,
this was done by nesting that menu in a section.
Doing so increases the complexity of the rules for GtkMenuTracker as you
may want different handling from inside of the section vs toplevel
sections.
If instead we synthetically glue the menus together, we have a much more
natural joining of menus as the application developer would expect for
their menu.
This also ports GtkLabel, GtkText, GtkPasswordEntry, and GtkTextView to
use the joined menu helper.
The joined menu helper comes originally from GNOME Builder and has had
extensive use there.
Fixes#4094
We hardcoded the typelib directory for only an arch (and a distro),
while we can just get it from gobject-introspection pkg config if tests
are enabled.
This shows how to use a layout manager in a widget,
implemented in javascript. The example sets up the
environment for running from the toplevel dir, assuming
that the build dir is called 'build'.
We need to update the visibility of the placeholder
label when we create it, otherwise we can end up
with placeholder text on top of entry content.
Fixes: #4066
This was showing up when calling some filechooser api on
a native filechooser, where we use a filechooser dialog
behind the scenes, but it does not have focus.
Fixes: #4077
This shows how to do custom drawing in a widget,
implemented in python. The example sets up the
environment for running from the toplevel dir,
assuming that the build dir is called 'build'.
In many cases across GtkTextBuffer, we end up with operations performed
inside of a begin/end user action. Those can be coalesced into a single
sub-action within the group, and hoisted out of the group. Doing so
increases the chances that we chain similar actions together for words.
Additionally, this fixes an issue introduced in
6179886b14 for #3977 where GNOME Text Editor
started to group all possible actions into a single group.
FixesGNOME/gnome-text-editor#97
Make sure the button still has the .image-button style class with an icon,
also add it to the initial state with only an arrow. Add a new
.arrow-button style class for the icon+arrow state so it's possible to
style it.
Remove spacing from the label+arrow variant to match, re-add it from the
stylesheet for both.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3501
In the refactoring from GdkWindow to GdkSurface, GtkWidget no longer
corresponds to a GdkSurface. We have to calculate the relative position
from GtkWidget to the GdkSurface.
Closes#4063.
The Trash is a special location: files cannot be copied or moved, there,
and the file selection dialog is not able to restore files from the
Trash.
Fixes: #674
The Trash is a special location: files cannot be copied or moved, there,
and the file selection dialog is not able to restore files from the
Trash.
Fixes: #674
This allows developers to modify the pango context that is used when
rendering text within the text view.
Such access can be useful to alter how rounding occurs with API such as
pango_context_set_round_glyph_positions() and is needed by GtkSourceView
for proper placement of glyphs within the overview map.
We must call gdk_drag_drop_done() when the drag ends,
successfully or not. Without this, we get an unwarranted
emission of ::cancel after a successful drop.
Since only the first call to gdk_drag_drop_done() is taking
effect, it is safe to call as a fallback, after emitting
::dnd-finished. If the application connects to that signal
and calls gdk_drag_drop_done() itself, its call will take
precedence.
This matches what the X11 implementation does.
We are pretty good at batching commands now, and we can easily
produce batches that exceed the maximum number of elements per
draw call that the hw can handle. Query that number, and respect
it when merging batches.
This fixes the rendering of the overview map in GtkSourceView.
Determine the root_x and root_y coordinates of the drag surface by
relying on the coordinates of the surface where the drag is being
carried out, plus the coordinates that we receive from the drag event,
which is in-line with what the X11 backend does.
This will prevent the drag surface from being initially drawn at the
correct position, but jumping towards the top-left corner of the screen
shortly afterwards.
The DnD support will still need some more updates to function correctly
on Windows, but at least this is a small improvement.
Fixes issue #3798.
This gets the basic mechanics of the drop portion of DnD working on the
macOS backend. You can drag, for example, from TextEdit into GNOME
Text Editor when using the macOS backend.
Other content formats are supported, and match what is currently
supported by the clipboard backend as the implementation to read
from the pasteboard is shared.
Currently, we look up the GdkDrag for the new GdkDrop. However,
nothing is stashing the drag away for further lookup. More work is
needed on GdkMacosDrag for that to be doable.
We will want to be able to reuse the pasteboard reading code from
the macOS DnD drop backend. This just removes the pasteboard
bits from the implementation and allows that to be passed in as in
both clipboard and DnD cases we'll have a specific NSPasteboard
to read from.
We don't want to overdraw when dragging a narrow column
around, and we also need the clipping to avoid picking
the wrong column, when a later column button overlaps
an earlier one.
Fixes: #4045
The normal way to associate accels with actions is
to attach a shortcut controller to the widget. The shorcut
controller will inject the accel into the action muxer
tree, so that it can get displayed in widgets that activate
the action (say, in menus.
This approach does not works for generated menus, since the
widgets are not in the hands of the app developer, so attaching
shortcut controllers to them is impractical.
Instead, GtkModelButton has an accel property that gets
bound to the accel coming from the action muxer tree (most
likely put there via gtk_application_set_accel_for_action),
and creates a shortcut controller itself.
The change in this commit is to prevent the shortcut controller
from injecting the accel into the action muxer tree in this case.
Otherwise, the accels get 'stuck' and we won't update them if the
global accels are later changed.
This is a hack, and needs a better solution.
We were pretty aggressive about not registering
observers further than necessary, stopping at the
first muxer that provides an action.
But even though action changes further up in the tree
won't be relevant in that case, we need to listen to
accel changes, since they may come from higher up
in the tree (e.g. when using
gtk_application_set_accels_for_action with an action
that is defined on a widget.
So, register all the way to the top, and stop propagating
action changes when we hit a muxer that provides the action.
In some cases (such as when getting a new parent), the
action muxer doesn't know exactly which detailed actions
have changed accels, so we call primary_accel_changed with
just an action name.
Make the menu tracker item handle that case by matching
either against the detailed name or the the action name.
Take the size from -gtk-icon-size.
Note that min-width/height still works, as those properties are handled
by the generic widget sizing machinery in GTK4.
If we are undergoing a surface move, just apply the next_layout anyways,
even if we are not moving a toplevel surface.
Update the way how we obtain the x and y coordinates of a surface, if it
is a toplevel, apply the x and y coordinates from the results from we
obtained the underlying Win32 HWND, as we did before. But if it is a
popup, use gdk_win32_surface_get_geometry() to obtain the correct x and
y coordinates to place our popup surface.
Also correct how we compute the shadow dimensions, and the final popup
rectangle as we attempt to layout the popup surface, since GDK-Win32
keeps track of the shadow dimensions in system (unscaled) units, not GDK
units.
Fixes issue #3793.
Also rename gtk_media_stream_ended to
gtk_media_stream_set_ended, to avoid naming
collision with GtkMediaStream:ended.
The existing entry points still exist, deprecated
and marked as non-introspectable.
Update all internal uses.
Fixes: #4023
Rename the GtkDropTraget:drop property to :current-drop,
to avoid naming collision with the signal of the same
name.
We leave the old property and getter in place, deprecated
and marked as non-introspectable.
Fixes: #4028
We were not handling the case right in which we
want to use underlines, but not use markup. Since
we are now using pango_parse_markup for this case,
we need to escape the xml markup.
Fixes: #4041
This reverts commit 95747b1a40.
This was wrong - it turns out that while GtkProgressBar
allows you to change its orientation, its box layout is
always vertical.
Fixes: #4037
Some bindings can't handle the coexistence of
GtkMediaStream:prepared and gtk_media_stream_prepared.
Help them out by renaming the function to
gtk_media_stream_set_prepared, and rename
gtk_media_stream_unprepared as well, to match.
The existing entry points still exist, deprecated.
Update all internal uses.
Fixes: #4023
Claim the gesture when we are activating a list item.
Otherwise we end up with double activations in
columnviews: first GtkColumnViewCell handles
the event, and then GtkListItemWidget handles
it again.
Fixes: #4015
If we have a GAction as model, we just have to let
the action helper handle the state updates. GtkButton
already calls gtk_action_helper_activate() for us.
v32 of the image includes wayland-protocols 1.21, and
other updates from Fedora 34.
While we are at it, drop gtk-doc from the image, and drop
the separate DOCS_IMAGE - no longer used.
The swipe gesture forces values in the spin button that are
"impossible" according to the adjustment. This can break things
in creative ways.
Ensure the steps provided are always multiples of the adjustment
step value, and keep the remainder for further interaction.
In the GTK3 days, the spin button was an entry, with buttons on
top, and the swipe gesture affected the input on the entry bits.
Now the spin button is a container, so this gesture in the capture
phase applies to all contained children (incl. buttons).
Attach this gesture to the entry itself, so the buttons are left
outside this business. The gesture is still in the capture phase
in order to prevent text selection/edition/etc to happen.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4008
gtk_tree_view_row_activated and the ::row-activated signal
can (and do) receive NULL for the column occasionally.
This is an introspection api change.
Fixes: #3828
__popcnt() is not supported for ARM nor ARM64 Visual Studio builds, so we must
use the fallback implementation as intrinsics are not supported for this
purpose on ARM/ARM64 Visual Studio builds.
GtkApplicationWindows size_allocate does not chain
up if the menubar is visible; don't forget to allocate
the tooltip window in that case.
Fixes: #3997
The releasing of grabs while a button is pressed (e.g. after starting dnd, or
dragging the window, or going to overview with a pressed button, etc...) was
generalized here in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1879.
However we shouldn't break all grabs here. In the case of grabbing popups,
compositors will still emit crossing events between client surfaces (e.g.
popping up and selecting a menu item via press-drag-release), breaking all
grabs here means inconsistent client state, that was
https://gitlab.gnome.org/GNOME/gtk/-/issues/2746.
That was fixed in mutter, by essentially making implicit grabs
owner_events=FALSE, however that breaks the mentioned use pattern entirely.
Mutter is changing this behavior back, so GTK should handle these crossing
events.
The grab that we are interested in breaking here is the implicit pointer
one. Popups will be dismissed via other means if the compositor says their
active grab needs breaking. This still leaves dnd/move/resize drags in
one place, while not allowing #2746 to happen with popups.
<span allow_breaks="false">A</span> hyphenation algorithm is a set of rules, especially one codified for implementation in a computer program, that decides at which points a word can be broken over two lines with a hyphen. For example, a hyphenation algorithm might decide that impeachment can be broken as <span allow_breaks="false">impeach‧ment</span> or <span allow_breaks="false">im‧peachment</span> but not <span allow_breaks="false">impe‧achment.</span>
hyphenation algorithm is a <span allow_breaks="false" style="italic">set of rules</span>, especially one codified for implementation in a computer program, that decides at which points a word can be broken over two lines with a hyphen. For example, a hyphenation algorithm might decide that impeachment can be broken as impeach‧ment or im‧peachment but not impe‧achment.
<span line_height='1.33'>Line height: This is an example of widely spaced text. It was achieved by setting the line-height factor to 1.33. You can set the line-height factor to any value between 0 and 10.
Note that the line height affects the spacing between paragraphs as well as between the wrapped lines inside a paragraph.</span>
Transforms: <span text_transform='uppercase'>straße</span> <span text_transform='capitalize'>up, up and away</span>
* snapshot at or 0 if none. This is purely a hint. The object must still
* be able to render at any size.
* @get_intrinsic_aspect_ratio: The preferred aspect ratio for this object
* or 0 if none. If both [vfunc@Gdk.PaintableInterface.get_intrinsic_width]
* and [vfunc@Gdk.PaintableInterface.get_intrinsic_height] return non-zero
* or 0 if none. If both [vfunc@Gdk.Paintable.get_intrinsic_width]
* and [vfunc@Gdk.Paintable.get_intrinsic_height] return non-zero
* values, this function should return the aspect ratio computed from those.
*
* The list of functions that can be implemented for the `GdkPaintable`
* interface.
*
* Note that apart from the [vfunc@Gdk.PaintableInterface.snapshot] function,
* Note that apart from the [vfunc@Gdk.Paintable.snapshot] function,
* no virtual function of this interface is mandatory to implement, though it
* is a good idea to implement [vfunc@Gdk.PaintableInterface.get_current_image]
* for non-static paintables and [vfunc@Gdk.PaintableInterface.get_flags] if the
* is a good idea to implement [vfunc@Gdk.Paintable.get_current_image]
* for non-static paintables and [vfunc@Gdk.Paintable.get_flags] if the
* image is not dynamic as the default implementation returns no flags and
* that will make the implementation likely quite slow.
*/
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
