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
It is enough to just set the parent (and make the parent
call gtk_native_check_resize in size_allocate).
This commit removes the relative_to argument to the
constructors of GtkPopover and GtkPopoverMenu, and
updates all callers.
The preview widget harks from a platform before time, when we didn't
have GIO, or a thumbnail specification.
Very few applications use it correctly, if at all; it has an horrid hack
to deal with the ownership of the widget's instance when accessed
through the getter function; it messes up the layout of the widget and
its label is less than useful when it comes to file names longer than a
dozen characters; it's a poor substitute for a proper thumbnail view.
GtkFileChooser's API predates GIO by a few years, so it started off with
filenames and URI as character arrays. After introducing GIO as a
dependency, the API included GFile-based entry points.
It's much more appropriate to use GFile everywhere, as we want to
encourage people to use GIO instead of passing random bytes to low level
POSIX API.
See: #2455
... and use one controller per button instead of using it on the
switcher and then going through lots of pain attempting to find the
right button for the location under the mouse.
Emit crossing events - with a new GTK_CROSSING_DROP type - like we do
for motion events. There is no more special casing for them.
Note that the gesture has not been updated yet, so some obscure behavior
may occur.
And in particular, only do it if the widget doesn't use ALIGN_FILL.
This avoids lots of measuring in the common case and speeds up
size_allocate() by about 25%.
And because size_allocate() is the bottleneck in the fishbowl, this also
gets ~25% more fishies.
Widgets should be given the actual size they will be allocated, so they
can do something with it.
If they want to clamp themselves to their natural size, nothing's
stopping them, they know their natural size after all.
It's the native's job to request a 1px x 1px size, not the job of
gtk_widget_size_allocate()
Also saves 10% of size_allocate() time because checking for an interface
is really expensive.
FIXME: Is this necessary?
Could the surfaces just clamp to 1x1 themselves?
We recently declared that surfaces can decide on whatever size they want
so natives need to inspect the size they requested anyway.
We are using (dddd) variants to store colors in variants,
which is dangerous now that GdkRGBA members are just floats.
Avoid passsing the GdkRGBA members directly to any varargs
functions.
We don't want to expose the GtkCrossingData struct, and manually
feeding events to event controllers is not something we want to
encourage, going forward.
Split the focus tracking into a separate
GtkEventControllerFocus, and change the API one more time.
We are back to having ::focus-in and ::focus-out signals.
Update all users.
Add fields for direct descendents to GtkCrossingData,
and populate them when emitting focus change events.
Also add accessors for these fields to GtkEventControllerKey,
and verify that they are set properly in the focus test.
Not done yet: Do the same for pointer crossing events.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
Instead of relying on gdk's antiquated crossing events,
create a new GtkCrossingData struct that contains the
actual widgets, and a new event controller vfunc that
expects this struct. This also saves us from making sense
of X's crossing modes and details, and makes for a
generally simpler api.
The ::focus-in and ::focus-out signals of GtkEventControllerKey
have been replaced by a single ::focus-change signal that
takes GtkCrossingData as an argument. All callers have
been updated.
We want to make events readonly, so stop translating
their coordinates and instead pass the translated
coordinates separately, when propagating events.
This is triggered by typing / or hitting Ctrl+L. Since we don't have a
visual indicator for this mode right now anyway, the reason for not
allowing it in recent mode cited in the comment just above the
early-exit is irrelevant.
Closes#2178
Replace the gdk_surface_move_to_rect() API with a new GdkSurface
method called gdk_surface_present_popup() taking a new GdkPopupLayout
object describing how they should be laid out on screen.
The layout properties provided are the same as the ones used with
gdk_surface_move_to_rect(), except they are now set up using
GdkPopupLayout.
Calling gdk_surface_present_popup() will either show the popup at the
position described using the popup layout object and a new unconstrained
size, or reposition it accordingly.
In some situations, such as when a popup is set to autohide, presenting
may immediately fail, in case the grab was not granted by the display
server.
After a successful present, the result of the layout can be queried
using the following methods:
* gdk_surface_get_position() - to get the position relative to its
parent
* gdk_surface_get_width() - to get the current width
* gdk_surface_get_height() - to get the current height
* gdk_surface_get_rect_anchor() - to get the anchor point on the anchor
rectangle the popup was effectively positioned against given
constraints defined by the environment and the layout rules provided
via GdkPopupLayout.
* gdk_surface_get_surface_anchor() - the same as the one above but for
the surface anchor.
A new signal replaces the old "moved-to-rect" one -
"popup-layout-changed". However, it is only intended to be emitted when
the layout changes implicitly by the windowing system, for example if
the monitor resolution changed, or the parent window moved.
Changing the autohide property means the popover needs to be remapped.
Remapping may need user interaction, so lets just unrealize the popover
if the property changes, forcing the application to remap it should it
be shown again.
Add properties, and use string arrays instead of lists.
Among other things, this renames gtk_icon_theme_list_icons
to gtk_icon_theme_get_icon_names.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2410
By running it in the capture phase, it will not be starved for events by
the button's click source and make drags actually start a color drag
operation.
Actually use GValues for the DND operation instead of sending GBytes of
pointer addresses through pipes.
This is a bit complicated because we need to special-case rootwindow
drops, because they're handled on the source side, so we need a custom
ContentProvider.
Enter the Emoji inseration in the undo history.
Also, stop stashing away the selection when we
pop up the Emoji chooser, and use the selection
as-is when we insert the Emoji.
The old code did mimetype checks everywhere when type compatibility has
since been moved to the GtkDropTarget::accept signal.
So the code can now just assume a compatible mime type exists.
Content providers are meant to be immutable, apart from very special
cases, but in those cases they need to emit
gdk_content_provider_content_changed().
Having a constructor that just uses a get_func invites abuse of this
by not making developers aware of those requirments.
In fact, all users in GTK failed to do this.
Instead, code should use the GtkDragSource::prepare signal to create
content providers when needed.
The same problem exists with gdk_content_provider_new_with_formats(),
but this commit doesn't touch that.
In Vala and JS at least, gtk_widget_get_css_name() and
gtk_widget_class_get_css_name() are resolved to
GtkWidget.get_css_name().
To avoid this problem, we rename the class version.
Accessors like these are weird to have and we can add widgets to the
content area via gtk_container_add() as well as add widgets to the
action area via gtk_info_bar_add_action_widget().
It seems that Meson's gnome.compile_resources() cannot deal with two
files with the same name under different directories, which breaks the
build parallelism because the GResource file ends up not depending on
either the Adwaita or the HighContrast gtk-contained.css file.
This commit only changes the on-disk names of the Adwaita and
HighContrast SCSS files, and the corresponding generated CSS files; the
files in the GResource are going to be aliased to the old file names, to
minimise the breakage. We might want to change the theme entry points at
some later date, if we decide to commit to this naming scheme.
Fixes: #2423
See Meson bug: https://github.com/mesonbuild/meson/issues/6615
These don't take a duration, instead they call g_get_monotonic_time() to
and subtract the start time for it.
Almost all our calls are like this, and this makes the callsites clearer
and avoids inlining the clock call into the call site.
When we use if (GDK_PROFILER_IS_RUNNING) this means we get an
inlined if (FALSE) when the compiler support is not compiled in, which
gets rid of all the related code completely.
We also expand to G_UNLIKELY(gdk_profiler_is_running ()) in the supported
case which might cause somewhat better code generation.
usec is the scale of the monotonic timer which is where we get almost
all the times from. The only actual source of nsec is the opengl
GPU time (but who knows what the actual resulution of that is).
Changing this to usec allows us to get rid of " * 1000" in a *lot* of
places all over the codebase, which are ugly and confusing.
As pointed out in https://gitlab.gnome.org/GNOME/gtk/issues/1481
and seen from critical warnings with swinging revealers in widget-factory
there are some size allocation issues in GtkRevealer.
What happens is that we request a size of the revealer itself
based on the child natural size and the current stage of the transition
by applying a scale to the natural size. We then round up to nearest
int size. However, we want the widget to render as if it did get the
natural size so we can transform it, rather than the scaled down size.
For example, a label should not start ellipsizing in the animation.
So we inverse the scale when allocating the child.
Unfortunately, for very small scales the inversion of the scale can
result in very large sizes, and for such scales we rounded up the
requested size to 1, so we will be allocating huuuuge children.
In order to avoid such issue we pick an arbitrary maximum upscale
scale factor of 100. This means that in the case where the allocated
size is 1 we never allocate the child at > 100 px. This means
that in large downscaling cases we may run into the clipping issue
described above. However, at these downscaling levels (100 times!)
we're unlikely to notice much detail anyway.
We can't just use the outline rect and apply the border radius because
the outline box is the border box grown by the outline offset, which
will also grow the resulting border radius.
Fixes#2425
We test this by looking at the produced render nodes now that
we don't actualluy scale the icon. Also, it turns out that this
code was broken due to some typos, so we also fix those.
If you called gtk_icon_theme_lookup(), then always return some useful
icon name from gtk_icon_paintable_get_icon_name(), even if we picked
an unthemed icon.
Also rewrite the gtk_icon_paintable_get_icon_name() docs to make this
clearer.
