Make GtkAspectFrame not derive from GtkFrame anymore,
since frames now always draw, well, a frame. Also,
add proper setters for the properties of GtkAspectFrame.
Update our sole user.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2627
The viewport draws a frame at the same place as
the scrolled window, so there is really no need
to have that ability in both. Just drop the frame
from viewports.
Always track visited state of links. This way all visited links in all
labels look the same. Whether the theme wants to style :visited is the
theme's business.
This makes it more obvious that gtk_label_setup_mnemonic() depends on
the root of the widget and it therefore makes sense to call it in
::root/::unroot.
Don't allocate a new GString if we never need it and therefore don't
create the PangoAttrList if we have no attributes anyway. Update callers
to handle the possible NULL return value.
Don't crash while picking. The event signal broke
when GdkEvent was turned into a type instance,
since the automatic marshallers don't know how to
deal with that. Manually set the right marshaller.
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.
Use :focus-within for focus in entries, since the
actual focus is on the text within, and :focus for
notebooks, since we don't want to draw an outline
around the notebook when the focus is in content.
This is used for widgets that contain the focus widget,
reserving the focused state for the focus location itself.
This aligns our focus state handling with
https://www.w3.org/TR/selectors-4/
which could happen after confirming the "file overwrite"
dialog and may result in a different file being overwritten
causing data loss.
The oblivious file selection can be done by a mouse
click or keyboard press sent inadvertently just after
confirming the "file overwrite" dialog (and before the
enclosing GtkfilechooserDialog is closed).
Fixed by adding a flag to ignore any button/key press
events sent to the file list. We set this flag just
after the user accepts the "file overwrite" dialog (which
means the enclosing GtkfilechooserDialog is about to
get closed). And we restablish the flag when the dialog
is shown again (in its map() handler).
Fixes data loss issue #2288
Stop rewriting key and focus events on the GDK side.
Instead deliver them as they are, and propagate them
from the root on the gtk side, in gtkmain.c. And
stop complaining about focus events on popups - we
can just ignore them if we have no use for them.
- People seem to misunderstand the unsharp-mask-like increase
of visual contrast for "fuziness". That is not the reason for
the change. The stylistic change of just going with flat
text label allows to simplify the code and drop complexity.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2280
- sligtly increase contrast for the treeview borders
- FIXME: High Contrast seems to drop the borders completely,
there might be some trickery for using border-left-color and
border-top-color this way as even forcing the color 'red' seems
to render invisible on HC.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2238
Without this, it seems impossible to make cross-section
keynav in the Emoji chooser work. I've tried, but got
lost between the focus, grab_focus, move_cursor and
keynav-failed vfuncs and signals, and their competing
implementations GtkFlowBox and GtkEmojiChooser.
Set version and soversion separately for the library.
When we do the 4.0 release, we will set:
gtk_soversion = '1'
gtk_library_version = '1.0.0'
See https://gitlab.gnome.org/GNOME/gtk/-/issues/1963
If we call any functions that may call ensure_layout
themeselves, we risk having the cached layout pulled
out from underneath. Better play it safe and take a
reference.
Make this a full async function, and add a simple wrapper.
Call gtk_show_uri_full() if you need control over the
results, and use gtk_show_uri() if you are fine with
ignoring any errors.
We have event controller apis to replace these.
There is one remaining use of gtk_get_current_event_time
in gtkwindow.c, so we can't drop the implementation yet.
Add a section in the migration guide for this.
This commit handles complicated cases where we selections.
We handle this by adding extend and modify parameters to
the ::move-cursor signals, and adjust the bindings
accordingly.
We don't really have an event anywhere close in most
cases, and we already pass GDK_CURRENT_TIME in half
the cases anyway.
If we want to be serious about this, we need to pass
the event itself, since future focus-stealing protocols
may not rely on just a timestamp.
We need to unset the propagation limit on the focus
controller, else we miss the focus-in when the focus
enters the popover upon initial popup, when it comes
from the parent button.
Add a .link style class on labels that contain links,
so we can avoid the focus outline around the label
when individual links are focused, and use the link
node when rendering the focus on links.
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 :can-focus property is no longer very useful to
give an indication of what is focusable, since it is
TRUE for almost all widgets now. Patch things up
to by looking at known widget types.
This is one of the situations, where can-focus can still
be used to tweak focus behavior of leaf widgets. Color
swatches are focusable by default to allow selecting colors
with the keyboard. But when used as color samples, they
should not take focus.
After the :can-focus change in the previous commit, widgets
need to set suitable focus and grab_focus implementations
to implement the desired focus behavior.
This commit does that for all widgets.
Make widgets can-focus by default, and change the semantics
of can-focus to be recursive . If it is set to FALSE, focus
can not enter the widget or its descendents at all anymore.
This commit temporarily breaks focus behavior of widgets
that did not expect to receive focus.
The only place where this should be set is when making
a widget the focus-widget of a window. We still keep
the property around in readonly form, since there are
a few places where we rely on property notification
for it.
This property doesn't carry any new information compared
to GtkWindow:focus-widget. We still keep the gtk_widget_is_focus
getter, as a convenient shortcut.
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.
