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.
We already skip them on the edited cell widget, but it's also a problem for
header buttons. Overall, there's no real reason to let it propagate here.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3996
In GTK 3, GtkStackSwitcher implemented GtkOrientable via the parent GtkBox
type. In GTK 4, that was changed to inherit from GtkWidget and lost this
interface implementation.
This adds that back, along with a note in the documentation that the
interface was added in GTK 4.4.
Fixes#3988
As app menu has been deprecated, the function of app menu should be
merged into the menubar, which behaves like the original API of NSApp.
This also brings back the default app menu, which looks like native
macOS apps.
For future refactoring, please note that the menubar must contain at
least one menu before being set to NSApp to avoid weird menubar
rendering.
Fixes#3967.
This was an oversight when porting the GtkTextHistory into GTK. We simply
need to bind the GtkTextBuffer action into the text history for grouping
to work correctly.
Fixes#3977
The gtk_print_run_page_setup_dialog() function, and its asynchronous
variant, are declared in the common gtkprintoperation.h header, but
implemented in different source files depending on the platform.
Make the "gl-context" property of the GstGLSink readable as well so that
we can query whether the GstGLContext sharing really succeeded. If it
did, then we proceed to playback our video using the glimagesink as we
did before. If it didn't, throw out the GtkGstSink we were creating, and
re-create the GtkGstSink without the "gl-context" property, meaning that
we won't be using the glimagesink in this case.
Add support to look for and use the EGL context in Windows if it was activated
instead of desktop OpenGL.
GstGL may have been built with or without EGL/libANGLE support, so if it were,
check in GstGL whether we have gst_gl_display_new_with_type() to create a
GstGLDisplay that is of the GST_GL_WINDOW_WIN32 type when we are using
Desktop OpenGL (WGL), otherwise we show messages indicating that envvars
need to be set to initialize GstGL properly.
Due to a bug in GstGL, the GstGLContext can only be set up successfully
if one of the following is true:
* An OpenGL 3.x or later emulator, such as Mesa is used (for WGL)
* The latest GstGL master is being used, at the time of writing (for
WGL)
* GTK, libepoxy and GstGL are all built only with WGL support (for WGL)
* EGL is being used in GTK at runtime
Special thanks to Matthew Waters for the help during the process.
Add support to share the WGL context in GDK with the WGL context in GStreamer,
so that we can also use OpenGL in the gstreamer media backend to playback
videos. For now OpenGL/ES is not supported for this under Windows.
The process of setting this up in Windows is a little bit more involved, as:
* The OpenGL support in GstGL requires a GL 4.1 Core context, but we may just
get the GL version from wglCreateContextAttribsARB() that we pass into the
attributes, which is 3.2 by default. So, try to ask for a 4.1 Core context
first if we are asking for anything less.
* There is only one GstDisplay available for Windows, so we just use
gst_gl_display_new().
* We must explicitly tell libepoxy that we are using wglMakeCurrent() outside
of libepoxy that is being used in GdkGL, otherwise we would end up crashing
as the GL/WGL function pointers would become invalid.
* We must also deactivate temporarily the underlying WGL context that was made
current by gdk_gl_context_make_current() so that when
gst_gl_display_create_context() calls wglShareLists(), we won't get bitten
by error 0xaa (resource busy), as some drivers don't handle this well when
the GL context is current in another thread.
For the last two points we make use of macros defined by the platforms that the
build is done for to help us carry out the necessary tasks as needed.
Thanks to Matthew Waters for the info on integrating GstGL and windowing
toolkits on Windows.
Visual Studio 2013's linker does not suport `/WHOLEARCHIVE:`, so just
explicitly extract the objects from the static libraries that will
form the final GTK DLL.
We want to find focusable children, so we need to look at
the focusable property, not at can-focus. This is a change
from GTK 3, where can-focus was the correct property to
look at.
The intention of the code is to find a focusable ancestor,
so it needs to look at the focusable property, not at
can-focus. This is a change from GTK 3, where can-focus
was the correct property to look at.
Fixes: #3965
Check that we are indeed running inside an Xorg server before enabling
the workaround.
XWayland or other nested X servers deadlock when that workaround is
applied.
Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
The script assumes that the git program is in the PATH which may not be always
the case, so if git was not found, fallback to the former behavior of making
VCS_TAG an empty string if the profile option was not set to 'devel'.
Also fix the call to the script so that we do indeed call GIT on the source GIT
repo so that we can get the right short SHA1 sum.
Re-organize the code a bit in the process, so that things seem cleaner.
We iterate here from the target widget up the toplevel checking
for the previous and new grab, there's however 2 bugs here:
- The check for is_shadowed was different to the check for was_shadowed
- The loop started with the assumption that the widgets did not hold
a grab, just to change it if the grab widget was found. (or maybe
it's the other way around? it's unclear with the differing checks
for past/present state).
Make these checks consistent, and ensure we start with the right
assumption for the past/present grabbing state, and accounting that
new/old grab widgets may or may not be part of the pick stack.
With gtk_grab_notify_foreach() just taking care of emitting crossing
notifications due to the GTK grab change, rename it to a more apt
gtk_synthesize_grab_crossing().
The _gtk_widget_grab_notify() function just (maybe) did a) reset
controllers and b) hide toplevels. The second part was a testing
remnant introduced in commit 024d832d94, not part of the original
fix.
Do the former more concisely, called from the place where we figure
out whether a widget's ability to receive events changed due to
GTK grabs. It's across those changes that we are interested in
resetting the controllers.
With the gestures being reset both ways, GtkWindowHandle (and
probably other) gestures are now able to reset after a GTK grab
takes input away (e.g. GtkMenuButton). This could be seen as
a sudden jump the next time they'd be dragged with the mouse,
as the gesture would "resume" the previous interaction.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3942
When a new sequence is added to a GtkGesture, its state is looked
in other gestures in the same group, and made to match in this
gesture. This however happened a bit too early, before the
gesture touchpoint was fully set up. As this may result in signal
emission and whatnot, it's a good idea to make it happen with a
fully set up touchpoint.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3946
The CI pipeline does not do a full clone, so we cannot use `git
rev-parse` to get the short SHA checksum for the current commit.
Of course, since nothing's ever easy, we cannot use vcs_tag() with a
custom command, so we need to generate our out `demo_conf.h` header
straight from a script.
Match GtkListBox, so it's possible to use the same styles for them.
Update GtkListView and GtkGridView docs to reflect that, fix a few gtk-doc
formatting leftovers along the way.
Make gsk_ngl_texture_library_pack always return
the position including the padding. And compute
texture coordinates accurately in all cases (we
were fudging the padding for standalone textures.
The indentation of new lines inside documentation blurbs must be smaller
than 4 spaces, otherwise the Markdown parser will consider the line to
be part of a pre-formatted code block.
Fixes: #3945
When configuring the inspector display, preserve
debug flags that affect which GL variant we pick.
Otherwise, we may end up with a GLX context on the
default display, and an EGL context on the inspector
one. This hopelessly confuses libepoxy, and things
don't go well when that happens.
If we want to add an EGL implementation for the X11 backend, we are
going to need to move the GLX bits into their own class. The first step
is to declare GdkX11GLContext as an abstract type, and then subclass it
into a GdkX11GLContextGLX type, which includes the whole GLX
implementation.
When loading the emoji data we just try to get the data for a language
while there may be territory specializations and emojibase provides
them.
So, split the loading function and try to load the data for the fully
defined language string (i.e. `it-ch`) before loading the generic one
for the language (i.e. `it`) and eventually falling back to the generic
english.
The change in 875a92b95f made labels strip
out underlines earlier, but overlooked that this made
mnemonics not work before the timeout to show them
has passed. That was unintentional. Make mnemonics
work regardless of their visibility, again.
| %GTK_ACCESSIBLE_STATE_CHECKED | “aria-checked” | #GtkAccessibleTristate | Indicates the current state of a [class@Gtk.CheckButton] |
| %GTK_ACCESSIBLE_STATE_CHECKED | “aria-checked” | `GtkAccessibleTristate` | Indicates the current state of a [class@Gtk.CheckButton] |
| %GTK_ACCESSIBLE_STATE_DISABLED | “aria-disabled” | boolean | Corresponds to the [property@Gtk.Widget:sensitive] property on [class@Gtk.Widget] |
| %GTK_ACCESSIBLE_STATE_EXPANDED | “aria-expanded” | boolean or undefined | Corresponds to the [property@Gtk.Expander:expanded] property on [class@Gtk.Expander] |
| %GTK_ACCESSIBLE_STATE_HIDDEN | “aria-hidden” | boolean | Corresponds to the [property@Gtk.Widget:visible] property on [class@Gtk.Widget] |
| %GTK_ACCESSIBLE_STATE_INVALID | “aria-invalid” | #GtkAccessibleInvalidState | Set when a widget is showing an error |
| %GTK_ACCESSIBLE_STATE_PRESSED | “aria-pressed” | #GtkAccessibleTristate | Indicates the current state of a [class@Gtk.ToggleButton] |
| %GTK_ACCESSIBLE_STATE_INVALID | “aria-invalid” | `GtkAccessibleInvalidState` | Set when a widget is showing an error |
| %GTK_ACCESSIBLE_STATE_PRESSED | “aria-pressed” | `GtkAccessibleTristate` | Indicates the current state of a [class@Gtk.ToggleButton] |
| %GTK_ACCESSIBLE_STATE_SELECTED | “aria-selected” | boolean or undefined | Set when a widget is selected |
#### List of accessible properties
Each property name is part of the #GtkAccessibleProperty enumeration.
Each property name is part of the `GtkAccessibleProperty` enumeration.
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.
