Despite the name, the test was not in fact showing
contents on map anymore, since widgets are visible
by default. Setting visible to FALSE makes the test
work as expected again.
We are comparing a transparent label to a transparent
text view, so need to make sure the caret does not show
up in the text view to ruin the comparison.
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
In the hope of making ci-only failures less of a black hole,
add a backtrace to the messsage for criticals.
This could eventually go into GLib (pass backtrace symbols along
as a log field for criticals), but for now this will do.
Make GtkScaleButton a widget that has a toggle button
as a child, just like all the other button widgets now.
The immediate benefit of this arrangement is to avoid
the "double focus" problem when we pop up the popup.
Update accessible, demos and tests to match.
The color editor shows a color picker button only if it
finds a suitable implementation, which it does not in ci.
So disable the focus-chain test for page 3.
This test was expecting to make existing widgets like
GtkBox focusable by setting :can-focus. That just doesn't
work anymore.
The focus chain testing that is done here is already
better covered by test-focus-chain, so lets just remove this.
The notebook grab_focus change in the previous commit made
backwards tabbing work as expected, and thereby changed the
output of one of the focus-chain tests.
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.
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.
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.
It is hard to avoid widgets with the same name in a
large ui file - try harder to record a full focus chain
before decide that we've wrapped, by including the widget
address in the comparison. Note that we don't include
the addresses in the generated output, since that would
make expected output vary from run to run.
We are setting the month property to 10 different values,
checking that the change succeeds. But the calendar defaults
to the current date, so on every 30th of the month, we
try to set a date of Febuary 30, which fails.
Lets fix this before the 31st, by setting the calendar
to a good date.
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.
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.
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
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.
For some reason, these tests are flaky in ci,
they always work locally for me. So, until
we use the data these tests produce for something,
lets just turn them off.
This makes meson actually parse the individual test
results. Most of the time, it does not make a difference,
but one case where it does is when all the individual
tests of a binary are skipped, meson will mark the
test as skipped.
The background-image-multiple.ref.ui file uses
non-existing properties, which gives us a g_warning,
and the glib test framework insists on treating
warnings as fatal, so we end up doing exit(133),
which in turn makes the meson TAP parser ignore
its xfails.
Comment out the nonexisting properties, so we can
fail properly, and then in turn xfail properly.
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.
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
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.
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.
This is in particular relevant for the ::is-focus property, because
updating that one doesn't cause enter/leave events.
But it also checks that notify and enter/leave happen in the right
order.
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 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
This tests was testing gestures by faking an event in the
middle of a window that has a hbox with an expanding image in it.
For me (and I guess this depends on all sorts of issues like whether
CSD is enabled, font sizes, etc) the hbox ended up centered horizontally
but not vertically (probably because of csd at the top), so no events
ever hit the inner widgets.
This is fixed by emitting the events at allocation.x/y of the
hbox, which should contain both the hbox and the image (as it expands).
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.
These are always set to the same value as the corresponding border
radius properties. They are also non-standard, so remove them and
replace them with the border radius properties everywhere.
Fixes#2414
These now render the paintable to a cairo surface and convert that
to a texture. This is sort of a hack, but its only used in two
special cases internally and in two hacky test apps.
This changes gtk_text_buffer_insert_texture() to
gtk_text_buffer_insert_paintable() which is strictly more useful
(as textures are paintables). It also fixes the code to actually
support drawing the paintables (as well as tracking changes
to the paintables.
If icon lookup fails or if loading it fails later, just always
fall back to the built in image-missing icon. Nobody is handling
missing icons in a sane way anyway.
If you *truly* need to handle missing icons, you need to manually
use gtk_icon_theme_has_icon().
While changing the loading code I also fixed an issue where it
was always passing "png" to pixbuf, now it also handles "xpm" if
that is the filename suffix.
We had a pretty complex setup where we tried to avoid scaling up themes from dirs
that specified a size. However, not only was it very complex, but it didn't quite
work with window scales, because when using e.g. a size 32 directory for 16@2x
the dir size is wrong anyway. Additionally it turns out most code either picks
an existing icon size, or uses the FORCE_SIZE flags, so it doesn't seem
like a useful behaviour.
This change drops the FORCE_SIZE flags, and always scales
icons. Additionally it moves the scaling of the icon to rendering,
which seems more modern, and allows us to (later) share icons loaded
for different sizes that happened to use the same source file (at
different scales).
Note that this changes the behaviour of
gtk_icon_paintable_download_texture() is it now returns the unscaled
source icon. However, ignore thats, as I plan to remove this function
and replace it with a way to render a paintable to a cairo-surface
instead.
It it hard to control which of the csd style classes we get,
since it depends on details of the X server or compositor.
Explicitly ignore this difference by replacing .solid-csd
with .csd in the output.
Stylecontexts are on their way out and I'm removing API that the
testsuite was relying on, so remove the tests.
Put the useful parts of the tests elsewhere.
Instead, rely on people passing fallbacks explicitly.
Alternatively, GThemedIcon provides the functionality to create
fallbacks, which is what GtkImage and the testsuite now use.
That method is slightly better, too, so the expected test results
have been updated accordingly.
