| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
... as discussed in the meeting.
|
| |
|
|
|
|
| |
We no longer use this widget anywhere.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to test the accessibility API, as well as the implementation
inside each widget. For that, we should expose an API that lets us
verify that a GtkAccessible has a given role, as well as a given
property.
The API follows the pattern of other GTest API:
- a macro to assert that a condition is respected
- a function that prints out the error message in case of failure
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ATContext type is meant to be used as the base class for
implementations of the assistive technology APIāthe actual mechanism
needed to communicate to components like the screen reader, or any other
AT.
Every time the widget state changes, the ATContext is meant to broadcast
the state change; and every time the AT queries the state of a UI
element, the ATContext is meant to provide that information.
We also have a "test" ATContext implementation, which is meant to be
used to write tests to verify that changes are propagated without
requiring a whole desktop session.
|
|
|
|
|
|
|
| |
GtkAccessible is an interface for accessible UI elements.
Currently, it doesn't do much except exist as a type; in the future, it
will be the entry point for all accessible state in GTK.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To build a better world sometimes means having to tear the old one down.
-- Alexander Pierce, "Captain America: The Winter Soldier"
ATK served us well for nearly 20 years, but the world has changed, and
GTK has changed with it. Now ATK is mostly a hindrance towards improving
the accessibility stack:
- it maps to a very specific implementation, AT-SPI, which is Linux and
Unix specific
- it requires implementing the same functionality in three different
layers of the stack: AT-SPI, ATK, and GTK
- only GTK uses it; every other Linux and Unix toolkit and application
talks to AT-SPI directly, including assistive technologies
Sadly, we cannot incrementally port GTK to a new accessibility stack;
since ATK insulates us entirely from the underlying implementation, we
cannot replace it piecemeal. Instead, we're going to remove everything
and then incrementally build on a clean slate:
- add an "accessible" interface, implemented by GTK objects directly,
which describe the accessible role and state changes for every UI
element
- add an "assistive technology context" to proxy a native accessibility
API, and assign it to every widget
- implement the AT context depending on the platform
For more information, see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2833
|
|
|
|
|
| |
Takes a boolean GtkExpression (like a boolean object property) to run a
filter with.
|
|
|
|
|
| |
This model presents the selection of a GtkSelectionModel
as its own list model.
|
|
|
|
| |
It has been superseded by GtkSignalsListItemFactory.
|
|
|
|
| |
GtkMultiSelection is so much faster than this that it isn't needed.
|
| |
|
|
|
|
|
|
| |
This is a list model holding strings, initialized
from a char **. String lists are buildable as well,
and that replaces the buildable support in GktDropDowns.
|
| |
|
|
|
|
|
| |
This is a listmodel similar to GtkDirectoryList,
for tracking recent files.
|
|
|
|
|
|
|
|
| |
This is a selection model that stores the selection
state in a boolean property of the items, and thus
persists across reordering and similar changes.
Fixes: #2826
|
|
|
|
|
|
| |
This is implemented using a private GtkSet helper.
Includes tests.
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no agreement that a coverflow widget is
appropriate for GTK 4.
It would be ok as a demo if it could live in gtk-demo,
but that requires us to make GtkListBase public first.
The demo is also somewhat rough and needs more work
to look plausible.
Drop GtkCoverFlow and the related demo for now.
|
|
|
|
| |
This is a simple drop down control using list models.
|
|
|
|
|
|
| |
This is a special-purpose sorter that can
apply the sorting of another sorter to the
levels of a GtkTreeListModel.
|
|
|
|
|
|
| |
So the poor Rust users can actually use this.
I would totally not use this ever!
|
|
|
|
|
| |
It's just a copy/paste of the listview code with all the internals
gutted. The code doesn't do anything.
|
|
|
|
|
|
| |
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 base item for GTK's list widgets so they can share some (read:
hopefully a lot of) code.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
GtkListItem is a generic row widget that is supposed to replace
GtkListBoxRow and GtkFlowBoxChild.
|
| |
|
|
|
|
|
| |
This sorter compares numbers obtained from items
by evaluating an expression.
|
|
|
|
| |
This is a sorter that tries multiple sorters in turn.
|
|
|
|
| |
This is a GtkSorter implementation collating strings
|
|
|
|
| |
This is a GtkSorter implementation which uses a GCompareDataFunc.
|
|
|
|
| |
This is a helper object for sorting, similar to GtkFilter.
|
|
|
|
|
|
| |
GtkMultiFilter is the abstract base class for managing multiple child
filter.
GtkAnyFilter and GtkEveryFilter are the actual implementations.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Adds a new listmodel called GtkDirectoryList that lists the children of
a GFile as GFileInfos.
This is supposed to be used by the filechooser.
|
|
|
|
|
|
| |
Keeping the layout manager type private does not
really work when it has layout child properties
that need to be usable in ui files.
|
|
|
|
| |
It is no longer used.
|
|
|
|
| |
This will allow to move the titlebar handling logic out from GtkWindow.
|
|
|
|
| |
It is no longer used anywhere.
|
|
|
|
|
|
|
| |
Move some code out of GtkHeaderBar and into a separate widget, making it
reusable in process.
See https://gitlab.gnome.org/GNOME/gtk/issues/2242
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Now that accel paths are gone, the object managing them isn't needed
anymore either.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The whole binding functionality is now handled by shortcuts.
|
|
|
|
|
| |
Triggers are meant to describe how to trigger a shortcut.
So far only a keyval + modifiers trigger exists.
|