Make gtk_window_set_focus call gtk_widget_grab_focus internally.
This means that set_focus can now end up putting the focus on
a child of the passed-in widget, and makes the focus-widget
property work for setting initial focus to (the child of) an
entry in a ui file.
After the header widget was introduced, focus would get
stuck in a loop between actions and tabs.
This could be seen in the notebook on page 3 of
widget-factory.
The third version of xdg-shell introduces support for explicit popup
repositioning. If available, make use of this to implement popup
repositioning.
Note that this does *NOT* include atomic parent-child state
synchronization. For that,
https://gitlab.freedesktop.org/wayland/wayland-protocols/issues/13 will
be needed.
This currently uses my own fork of wayland-protocols which adds meson
support, so that we can use it as a subproject. Eventually when
wayland-protocols' meson support lands upstream, we should change it to
point there.
Silence some meson warnings while at it to make CI happy.
This also bumps the glib requirement, since g_warning_once() is used.
- introduce two new colors: $focus_border_color for focused / outlined elements and $_coloured_focus_border_color for focused / outlined elements with a colored background color, like suggested/destructive buttons or selected elements
- set outline / focus color, offset and style accordingly for all widgets
- adapt entry focus color
Remove the plug/socket exception, and add exceptions for non-X11
windowing systems.
Additionally, speed up the file generation by avoiding string
concatenation in Python.
Language bindings—especially ones based on introspection—cannot deal
with custom type hiearchies. Luckily for us, GType has a derivable type
with low overhead: GTypeInstance.
By turning GskRenderNode into a GTypeInstance, and creating derived
types for each class of node, we can provide an introspectable API to
our non-C API consumers, with no functional change to the C API itself.
The proper way to do this would be to adapt the tables
to have the right data for the platform. Since 4.0 is
a new start in many ways, lets clean this up.
We don't need all of them, only the ones that contain public API. This
allows us to reduce the chance of a stray symbol getting incorrectly
added to the introspection data.
This broke when the event type check in gdk_key_event_matches
was removed and replaced by a precondition that accepts both
key press and release events.
Add the check in gtk_keyval_trigger_trigger instead.
Our new approach to modifiers works with a fixed set,
there is really no need to customize the modifier
masks if the backends are all supposed to deliver
the same modifiers.
Reviewing the existing settings, the only backend with
some differences in the modifier intent settings is OS X,
and we would rather have that implemented by interpreting
the existing modifiers in the appropriate way.
X11 Wayland Win32 OS X
primary ctrl ctrl ctrl mod2
mnemonic alt alt alt alt
context menu - - - ctrl
extend sel shift shift shift shift
modify sel ctrl ctrl ctrl mod2
no text alt|ctrl alt|ctrl alt|ctrl mod2|ctrl
shift group varies - - alt
GTK now uses the following modifiers:
primary ctrl
mnemonic alt
extend sel shift
modify sel ctrl
no text alt|ctrl
The context menu and shift group intents were not used
in GTK at all.
Update tests to no longer expect <Primary> to roundtrip
through the accelerator parsing and formatting code.
This code needs to be redone differently, since keymaps are no
longer going to be exposed. There should really not be this much
ifdef-ed backend-specific code here anyway. Or any, really.
Add all of the keyboard translation results in the key event,
so we can translate the keyboard state at the time the event
is created, and avoid doing state translation at match time.
We actually need to carry two sets of translation results,
since we ignore CapsLock when matching accelerators, in
gdk_event_matches().
At the same time, drop the scancode field - it is only ever
set on win32, and is basically unused in GTK.
Update all callers.
These are never used in practice, and we never want to
see them in the UI, so stop supporting them. This is
in preparation for cleaning up GdkModifierType.
The colorbutton contains a button which contains a colorswatch.
We want the focus to go straight to the button, nowhere else,
so mark the swatch as !can-focus.
Adapt tests to match.
In the paths where len > MAX_LEN and cursor/anchor are separated by
at least MAX_LEN from text edges, we were clamping the right end of
the surrounding string at MAX_LEN. Oops.
This end anchor may go as far as the string length, although just
up to len - MAX_LEN in real terms (due to the condition above that
caches cursor/anchor positions being near enough the text end).
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2565
(cherry-picked from commit d7fb15c822)
When we reconfigure, `configure_file()` is called again, and
`*.gresource.xml` files are regenerated, which causes many (all?)
binaries to be relinked. Now we only write those out if the contents
actually changed (or if the output didn't already exist).
This is exactly what Meson already does with `configure_file()` when
`command:` is not used.
While we're at it, also do the same for `gen-c-array.py` and
`gentypefuncs.py` for completeness. Now even if the input to those
changes, re-building of those custom targets may not result in
relinking if the outputted C files have the same contents.
Entries and menubuttons are no longer focusable themselves,
they have focusable children. Since we don't have accessible
objects for those, transfer the focus-related state (focusable
and focused) from the children to the main accessible object.
We don't get a focus-out on the event controller, when
the surface is losing keyboard focus, since we are not
moving our focus to some other widget, so we are never
unsetting the mnemonics-visible property. Do that in
response to surface state changes instead.
We are not loading the Compose file for individual contexts,
it just gets added to a global list. So don't pass an im context
along. This will let us move the loading out of the initialization
of individual contexts, and only do it once.
We were not properly setting the new_descendent field
in Crossing structs for GTK_CROSSING_OUT events. This
was causing extraneous ::leave signals to be emitted,
and make model buttons in popover menus flicker when
hovered.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2536
Under grabbing circumstances we used to get several crossing events,
some corresponding to the grab itself and some corresponding to
pointer motion.
The backends now do a better job at keeping those simple, which
means we sit listening for events that don't actually arrive. This
triggers pointer focus issues when dragging windows or opening
grabbing popups.
Actually obey those events, they will be the only ones we get now.
When no printer has been selected (e.g. because we don't
find any printers), the 'print at' radio group should be
insensitive, except for the 'now' choice. Selecting another
option in this situation will lead to a crash.
When we stopped translating event coordinates in-place,
this function inadvertently started returning surface-relative
bounding boxes instead of widget-relative ones, as expected.
Fix this by using the widget-relative coordinates that we
already store.
We no longer translate event coordinates in-place,
so gdk_event_get_position() returns surface-relative
coordinates, not widget-relative ones. Just use the
coordinates we are given.
After commit 2ab9be54fb we had to rename
the generated CSS files to be included into the GResource bundle; we
kept the URI stable to avoid too much churn, and allow backporting the
change to the 3.24 stable branch. This had the adverse effect of making
it harder to debug issues, as the on-disk file name does not match the
location in the GResource that will be used to print out warnings,
errors, and debugging messages.
We're not returning a full reference for GtkNeverTrigger, but we are
returning full references for mnemonic and keyval triggers; this means
we're either going to leak mnemonic and keyval triggers if we consider
this function a "transfer none" one, or we are going to trigger an
assertion failure when finalizing a never trigger, if we consider this
function a "transfer full" one.
Let's be consistent, and always return a full reference to the caller.
Unfortunately, this involves copying a bunch of
code from gtkwindow.c. The only difference here
is that we add a private method to turn this off,
which will be used by GtkPopoverMenu to implement
its own auto mnemonics.
When a model button in a popover displays a shortcut,
it is probably from the global shortcut controllers,
and will not work inside the popover, since that is
a different native. Install a shortcut using the same
trigger that just activates the model button. This
shortcut will end up in the managed shortcut controller
of the popover.
The lightweight inheritance mechanism used for GtkShortcutTrigger is not
going to be usable by bindings, because boxed types cannot have derived
types.
We could use GTypeInstance and derive everything from that, like
GParamSpec, but in the end shortcuts are not really a performance
critical paths, unlike CSS values or render nodes.
Make GtkShortcutController collect matching shortcuts
in the same way GtkKeyHash did (accept fuzzy matches
if we don't have any exact matches), and cycle among
the matches if we have multiple.
Copy the logic from GtkKeyHash for matching key events
to shortcuts.
Adapt shortcuts test to work with the better matching,
by creating more complete key events.
Allow GtkShortcutTrigger to return partial matches.
Currently, no triggers produce such results, and
GtkShortcutController treats partial matches like
exact ones.
People should use shortcut controllers instead (global, capture).
A side effect of this is that GtkAccelLabel now lost its method to
magically look up accelerators to display. Somebody needs to add that
back later.
API remains the same, but activation is now done via a
shortcutcontroller.
The code uses a controller with global scope so that the
shortcuts are managed with all the other global shortcuts.
This is mainly for internal use, but I can't see a reason to not have it
public for people who want to maintain their own lists.
I'm sure gnome-builder will never ever find a way to misuse it.
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
It's an outdated technology now that everybody is using GActionGroups.
If somebody wanted to support changeable shortcuts, they'd need to
reintroduce it in another way.
This adds an interface for taking care of shortcut controllers with
managed scope.
Only GtkWindow currently implements this interface, so we need to ensure
that we check if any top-level widget we reach is a shortcuts manager
before we call into it.
Mnemonics need to be triggered with help from the controllers (who
determine the modifiers). Support for that has been added, too.
Mnemonics do not use this yet though.
Allow setting the scope for a controller. The scope determines at what
point in event propagation the shortcuts will be activated.
Local scope is the usual activation, global scope means that the root
widget activates the shortcuts - ie they are activated at the very
start of event propagation (for global capture events) or the very end
(for global bubble events).
Managed scope so far is unimplemented.
This is supposed to be used to replace accelerators and mnemonics.
The function lives in gtkaccelgroup.c, so there's no need to have that
call a private function in another source file. Instead, make that
other source file call gtk_accelerator_get_label() instead.
The shortcut controllers are limited to same-native,
so we need to duplicate the Tab and arrow key bindings
for focus handling, as well as the Enter bindings for
activation.
And use it.
I just added it to GtkWidget just to show that I can.
The real reason I want it is for gamepad/joystick triggers
in games, so that it becomes possible to select 2 different
triggers (gamepad and keyboard) for the same shortcut.
This is a very barebones controller that currently does nothing but
activate the binding signals. Yay.
And because we have bindings on every widget (Yes, a GtkGrid has a
keybinding - 2 in fact), we need that controller everywhere.
This function is the replacement for
gtk_binding_entry_add_signall().
The GVariant will be demarshalled and passed to the action signal upon
binding activation. The same rules apply as used to apply for
GtkBindingArg, in that long, double and string args are now replaced by
"x", "d" and "s" variant types.
Add an api to retrieve the model containing a given
item in a flatten listmodel. This is useful when the
individual items in the list don't have backpointers.
We need to cleanup state here immediately so that we do not potentially
access the g_class private data after it been finalized. This ensures that
the borrowed reference is dropped by the muxer.
We used to either make the inspector see- and click-thru
or lower it, but sadly translucency broke after we
removed surface opacity, and lowering doesn't work
on Wayland. So just hide the inspector window while
we are picking.
Fixes: #2528
When inserting Pango markup into a text buffer, translate
Pango attributes for overlines and hyphenation control
into the corresponding text tag properties.
Add support for recently added Pango attributes
for overlines and hyphenation control. The new
properties of GtkTextTag are
overline, overline-rgba, allow-breaks, show-spaces
and insert-hyphens.
Before this commit, adding GtkWidgetAction to class private data would
require copying the actions to each subclass as they were built or
modified. This was convenient in that it is a sort of "copy on write"
semantic.
However, due to the way that GTypeInstance works with base _init()
functions, the "g_class" pointer in GTypeInstance is updated as each
_init() function is called. That means you cannot access the subclasses
class private data, but only the parent class private data.
If instead we use a singly linked list of GtkWidgetAction, each subclass
has their own "head" yet all subclasses share the tail of the
GtkWidgetAction chain.
This creates one bit of complexity though. You need a stable way to know
which "bit" is the "enabled" bit of the action so we can track enabled
GAction state. That is easily solved by calculating the distance to the
end of the chain for a given action so that base classes sort ahead of
subclasses. Since the parent class always knows its parent's actions, the
position is stable.
A new dynamic bitarray helper also helps us avoid allocations in all the
current cases (up to 64 actions per widget) and dynamically switches to
malloc if that is to ever be exceeded.
We want access to the private data from the action muxer so we can just
move the structures to the gtkwidgetprivate.h header. Alternatively we
could create accessors, but given that we'll probably need to use this
in other areas, seems reasonable to just put it there.
The problem is caused by gtk_im_multicontext_set_slave(), which forgets
to disconnect these signal handlers:
* gtk_im_multicontext_retrieve_surrounding_cb
* gtk_im_multicontext_delete_surrounding_cb
If slave GtkImContext emits signal after GtkIMMulticontext context is
destroyed, this leads to reading freed memory, sometimes causing a crash.
Fixes: #2365
At the bottom, it sometimes has to fight for the same position than
text handles, besides might not be ergonomically convenient (eg.
finger/hand partly covering the popover). Move it at the top to fix
both.
At the bottom, it sometimes has to fight for the same position than
text handles, besides might not be ergonomically convenient (eg.
finger/hand partly covering the popover). Move it at the top to fix
both.
This ensures the popover will follow the new position parameters. This is
necessary for popovers like the text magnifier that can be repositioned
while visible.
Instead of being a GObject managing two GtkWidgets, make GtkTextHandle
a GtkWidget subclass, representing a single handle.
From the perspective of users (GtkText and GtkTextView), this is not a
big leap since they have to be aware of a great deal of text handles'
state. It actually makes things more direct and simple.
With text handles being widgets, those can be actual children of the
widget, and may have their own GdkSurface that we move around at will.
This is the second major aspect of this refactor.
People should use shortcut controllers instead (global, capture).
A side effect of this is that GtkAccelLabel now lost its method to
magically look up accelerators to display. Somebody needs to add that
back later.
API remains the same, but activation is now done via a
shortcutcontroller.
The code uses a controller with global scope so that the
shortcuts are managed with all the other global shortcuts.
Reduce the amount of special casing by using a list model
for global and managed shortcuts, too.
This way, the ListModel API will work for the ShortcutController in the
GtkShortcutManager and GtkRoot.
The only special case remaining is shortcut activation, which needs to
pass the right widget to the controller in the global/managed case.
This is mainly for internal use, but I can't see a reason to not have it
public for people who want to maintain their own lists.
I'm sure gnome-builder will never ever find a way to misuse it.
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
- Activate a GAction
It's an outdated technology now that everybody is using GActionGroups.
If somebody wanted to support changeable shortcuts, they'd need to
reintroduce it in another way.
This adds an interface for taking care of shortcut controllers with
managed scope.
Only GtkWindow currently implements this interface, so we need to ensure
that we check if any top-level widget we reach is a shortcuts manager
before we call into it.
Mnemonics need to be triggered with help from the controllers (who
determine the modifiers). Support for that has been added, too.
Mnemonics do not use this yet though.
Allow setting the scope for a controller. The scope determines at what
point in event propagation the shortcuts will be activated.
Local scope is the usual activation, global scope means that the root
widget activates the shortcuts - ie they are activated at the very
start of event propagation (for global capture events) or the very end
(for global bubble events).
Managed scope so far is unimplemented.
This is supposed to be used to replace accelerators and mnemonics.
The function lives in gtkaccelgroup.c, so there's no need to have that
call a private function in another source file. Instead, make that
other source file call gtk_accelerator_get_label() instead.
The shortcut controllers are limited to same-native,
so we need to duplicate the Tab and arrow key bindings
for focus handling, as well as the Enter bindings for
activation.
And use it.
I just added it to GtkWidget just to show that I can.
The real reason I want it is for gamepad/joystick triggers
in games, so that it becomes possible to select 2 different
triggers (gamepad and keyboard) for the same shortcut.
This is a very barebones controller that currently does nothing but
activate the binding signals. Yay.
And because we have bindings on every widget (Yes, a GtkGrid has a
keybinding - 2 in fact), we need that controller everywhere.
This function is the replacement for
gtk_binding_entry_add_signall().
The GVariant will be demarshalled and passed to the action signal upon
binding activation. The same rules apply as used to apply for
GtkBindingArg, in that long, double and string args are now replaced by
"x", "d" and "s" variant types.
If we have never seen a GtkTextTag in the GtkTextTagTable with the
invisible bit set, then we do not need to go through the process of
checking the accumulated tags.
Not using invisible tags is overwhelmingly the common case.
The shortcut controllers are limited to same-native,
so we need to duplicate the Tab and arrow key bindings
for focus handling, as well as the Enter bindings for
activation.
These fixes were done blindly, to make the ci pass,
and will need review by somebody with access to an
actual win32 system to make sure the surface subtypes
are implemented properly.
There is no shape combining going on anymore, so
call this just gdk_surface_set_input_region, and
remove the offset arguments too. All callers pass
0 anyway.
Update all callers and implementations.
The label and action_name entries of GtkPadActionEntry are supposed to
be const, so copy them into a private ActionEntryData struct that we
later free.
The iter may be invalid, so we may not read from it.
testsuite/gtk/treemodel tests this and valgrind is shouting about it,
but it never crashed until I just ran it...
This bug is from 2004 and the test is from 2007. I guess invalid memory
accesses don't get caught by CI much.
Sprinkle various g_assert() around the code where gcc cannot figure out
on its own that a variable is not NULL and too much refactoring would be
needed to make it do that.
Also fix usage of g_assert_nonnull(x) to use g_assert(x) because the
first is not marked as G_GNUC_NORETURN because of course GTester
supports not aborting on aborts.
The `rename-to` annotation is used to "shadow" a symbol with another
one, which means both symbols need to exist. It can't be used to rename
a symbol to something else.
This way, we can ensure that for local same-type drops the GValue
is set when ::enter is emitted.
This is the common case for dnd between widgets inside larger
applications, so it's worth it to speed it up.
Before, gtk_drag_icon_new_for_drag() allowed creating new drag icons.
This could cause multiple drag icons to exist for a single drag.
Now, gtk_drag_icon_get_for_drag() makes sure that only one drag icon is
created.
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
First, it should have been a GdkDrop, but even then, proper DND code
should not rely on internals.
It's only been used in an unused signal emission anyway.
This might happen for slow filesystems where a fast-content-type might
be provided instead. Don't try to manipulate that content_type if it's
NULL, otherwise we'll either throw warnings (at best) or crash (at
worse).
Conflicts:
gtk/gtkfilechooserwidget.c
