The widget mostly works out of the box, but some tweaking may be
necessary (in particular in the theme) and the gtk-demo changes might
require removing before this is production-ready.
This is a container widget that takes over all the duties of tree
expanding and collapsing.
It has to be a container so it can capture keybindings while focus is
inside the listitem.
So far, this widget does not allow interacting with it, but it shows the
expander arrow in its correct state.
Also, testlistview uses this widget now instead of implementing
expanding itself.
Due to the many different ways to set factories, it makes sense to
expose them as custom objects.
This makes the actual APIs for the list widgets simpler, because they
can just have a regular "factory" property.
As a convenience function, gtk_list_view_new_with_factory() was added
to make this whole approach easy to use from C.
Users provide a search filter and an expression that evaluates the items
to a string and then the filter goes and matches those strings to the
search term.
GtkExpressions allow looking up values from objects.
There are a few simple expressions, but the main one is the closure
expression that just calls a user-provided closure.
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.
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.
This is a useful widget to have, and it has minimal api.
Not having it public forces apps to recreate a lot of
complicated machinery for not good reason, if they need
an Emoji chooser in a different context.
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.
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
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.
This is a new object (well, boxed type, but I'm calling it object) for
dealing with transform in a more constructive way than graphene_matrix_t
by keeping track of how the transform was created.
This way, reasoning about the transform becomes easier, and we can create
better ways to print it or transition from one transform to another one.
An example of this is that while a 0 degree and a 360degree rotation are
both the identity matrix, doing a transition between the two would cause
a rotation.
This commit introduces GtkPicture, which is supposed to complement
GtkImage.
GtkImage will be adapted to always display an icon, while
GtkPicture displays regular imagery.
This is a GtkGesture done to deal with stylus events from drawing tablets.
Those have a special number of characteristics that extend a regular
pointer, so it makes sense to wrap that.
This event controller is meant to replace usage from key-press/release-event
handlers all through. Optionally it can be set a GtkIMContext, so interaction
is carried by the controller.
Add an extension point called gtk-im-module, which requires
the type GtkIMContext. Simplify the loading by using GIO
infrastructure. Drop the locale filtering for now, I don't
think it is really necessary nowadays.
Convert existing platform modules to gio modules.
Sill to do: Drop the conditional build machinery.
Either always include them, or never.
This is a bit of filechooser internals that gets shared with
nautilus, which is fine, but it shouldn't be part of our
public API. There are no other users than nautilus.
