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
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.
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.
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
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.
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.
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 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.
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 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.
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.
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
Instead of requiring sassc to be installed add meson subprojects
which build libsass and sassc (currently both forks of mine, tested
under linux/mingw/msvc) when needed.
This allows us to drop the generated .css files and build scripts from git.
See #1502
Previously, we wrapped all GtkCssShadowValues in a GtkCssShadowsValue,
even if it was just one shadow. This causes an unnecessary bloat in
css values.
Make each GtkCssShadowValue able to handle multiple shadows instead, and
use gtk_css_shadow_value* API everywhere.
The differenciation between a literal color value and an RGBA value
caused problems in various situations. Just treat the two the same but
don't allow access to the rgba value of a non-literal color value.
This gets rid of around 1.6k rgba values in the widget-factory.
This is a GtkRoot implemntation for drag icons,
using the surface provided by GdkDrag. This lets
us avoid GTK_WINDOW_POPUP and
gtk_window_set_hardcoded_surface.
GtkBuilderScope is an interface that provides the scope that a builder
instance operates in.
It creates closures and resolves types. Language bindings are meant to
use this interface to customize the behavior of builder files, in
particular when instantiating templates.
A default implementation for C is provided via GtkBuilderCScope (to keep
with the awkward naming that glib uses for closures). It is derivable on
purpose so that languages or extensions that extend C can use it.
The reftest code in fact does derive GtkBuilderCScope for its own scope
implementation that implements looking up symbols in modules.
gtk-widget-factory was updated to use the new GtkBuilderCScope to add
its custom callback symbols.
So it does it different from gtk-demo, which uses the normal way of
exporting symbols for dlsym() and thereby makes the 2 demos test the 2
ways GtkBuilder uses for looking up symbols.
We use a compilation symbol in our build to allow the inclusion of
specific headers while building GTK, to avoid the need to include only
the global header.
Each namespace has its own compilation symbol because we used to have
different libraries, and strict symbol visibility between libraries;
now that we have a single library, and we can use private symbols across
namespaces while building GTK, we should have a single compilation
symbol, and simplify the build rules.
It's old and busted, and mostly broken in weird ways when it comes to
extended input devices. All that XIM does, these days, is make a mess
when people enable it by mistake.
Some of the CSS API has been moved to a public namespace, so we need to
include it into the introspection data we build in order for people to
use it.
Fixes: #2230
The GtkTextHistory helper provides the fundamental undo/redo stack that
can be integrated with other text widgets. It allows coalescing related
actions to reduce both the number of undo actions to the user as well as
the memory overhead.
A new istring helper is used by GtkTextHistory to allow for "inline
strings" that gracefully grow to using allocations with g_realloc(). This
ensure that most undo operations require no additional allocations other
than the struct for the action itself.
A queue of undoable and redoable actions are maintained and the link for
the queue is embedded in the undo action union. This allows again, for
reducing the number of allocations involved for undo operations.
This creates a new GtkTextViewChild that can manage overlay children at
given x,y offsets in buffer coordinates. This simplifies GtkTextView by
extracting this from GtkTextWindow as well as providing a real widget for
the borders.
With this change, we also rename gtk_text_view_add_child_in_window() to
gtk_text_view_add_overlay(). For those that were using
GTK_TEXT_WINDOW_WIDGET, they can use a GtkOverlay. It does not appear
that anyone was using GTK_TEXT_WINDOW_(LEFT|RIGHT|TOP|BOTTOM) for widgets
in this fashion, but that can be done by setting a gutter widget with
gtk_text_view_set_gutter(). We can make GtkTextViewChild public if
necessary to simplify this should it become necessary.
GtkTextViewChild will setup a CSS node of either "text" or "border"
depending on the GtkTextWindowType.
The old GtkTextViewChild has been renamed to AnchoredChild as it is only
used for widgets with anchors in the GtkTextBuffer. This also removes the
use of allocated GSList and instead embeds a GQueue and GList to save a
few extraneous allocations.
This adds a GtkTextLineDisplayCache which can be used to cache a number
of GtkTextLineDisplay (and thus, PangoLayout) while displaying a view.
It uses a GSequence to track the position of the GtkTextLineDisplay
relative to each other, a MRU to cull the least recently used display,
and and a direct hashtable to lookup display by GtkTextLine.
We only cache lines that are to be displayed (!size_only). We may want to
either create a second collection of "size_only" lines to speed that up,
or determine that it is unnecessary (which is likely the case).
This removes the use of GtkTextDisplay (a PangoRenderer) to use
the GskPangoRender which generates render nodes. Part of this means
improving the GskPangoRenderer to support the necessary features for
displaying a GtkTextView.
Primarily, this is a merging of GtkTextDisplay features into
GskPangoRender. Additionally, GtkTextDisplay was removed to allow for
gtk_text_layout_snapshot() to be implemented elsewhere.
This commit moves GtkConstraintGuide into its own
source files to avoid gtkconstraintlayout.c turning
too messy, adds max size properties and implements
getters and setters.
GtkConstraintSolver is an implementation of the Cassowary constraint
solving algorithm:
http://constraints.cs.washington.edu/cassowary/
The Cassowary method allows to incrementally solve a tableau of linear
equations, in the form of:
x = y × coefficient + constant
with different weights, or strengths, applied to each one.
These equations can be used to describe constraints applied to a layout
of UI elements, which allows layout managers using the Cassowary method
to quickly, and efficiently, lay out widgets in complex relations
between themselves and their parent container.
The only cases of stateful actions we've seen
so far have been boolean properties, and we
don't really want to add much state handling
API, so lets just go with property actions
for now.
Adapt the only user in GtkText.
This library is meant to be the new CSS library that gets used from GDK,
GSK and GTK for string printing and parsing.
As a first step, move GtkCssProviderError into it.
While doing so, split it into GtkCssParserError (for critical problems)
and GtkCssParserWarning (for non-critical problems).
The need of a specialised fixed layout container that can be placed into
a GtkScrolledWindow ceased to exist once GtkScrolledWindow gained the
ability to automatically interpose a GtkViewport when adding a child
that does not implement GtkScrollable.
All the other justifications that led to the existence of GtkLayout as a
separate widget from GtkFixed have been largely made irrelevant in the
20 years since its inception.
- Rename GtkLegacyLayout to GtkCustomLayout
- Use for() to iterate over children in GtkBinLayout
- Whitespace fixes for code imported from GtkBox
- Store the GtkLayoutChild instances inside LayoutManager
- Simplify the GtkLayoutManager API by dropping unnecessary arguments
- Fix the ownership model of GtkLayoutManager
GtkLegacyLayout is a layout manager for the transitional period between
the introduction of layout managers and the removal of GtkWidget virtual
functions for the size negotiation.
Layout managers needs a way to store properties that control the layout
policy of a widget; typically, we used to store these in GtkContainer's
child properties, but since GtkLayoutManager is decoupled from the
actual container widget, we need a separate storage. Additionally, child
properties have their own downsides, like requiring a separate, global
GParamSpecPool storage, and additional lookup API.
GtkLayoutChild is a simple GObject class, which means you can introspect
and document it as you would any other type.
A base abstract class for layout manager delegate objects.
Layout managers are associated to a single widget, like event
controllers, and are responsible for measuring and allocating the
children of the widget they are bound to.
