It feels slightly wrong to have GtkOrientable operate on widgets, but at
least what happens when an orientable widget changes orientation should
be part of GtkWidget.
This will allow to add more state changes without accessing widget state
from the outside of gtkwidget.c.
Rename the show-separators property to show-row-separators,
and add a matching show-column-separators property. It is
implemented by setting the .column-separators style class
on the column view.
This is a somewhat large commit that:
- Adds GtkColumnViewSorter
This is a special-purpose, private sorter implementation which sorts
according to multiple sorters, allowing each individual sorter to be
inverted. This will be used with clickable column view headers.
- Adds a read-only GtkColumnView::sorter property
The GtkColumnView creates a GtkColumnViewSorter at startup that it uses
for this property.
- Adds a writable GtkColumnViewColumn::sorter property
This allows defining per-column sorters. Whenever an application sets a
sorter for a column, the header becomes clickable and whenever
a header is clicked, that column's sorter is prepended to the list of
sorters, unless it is already the first sorter, in which case we invert
its order. No column can be in the list more than once.
This uses a custom GtkColumnViewTitle widget. So far that widget is
pretty boring, but that will change once we added
resizing, reordering, dnd, sorting, hiding/showing of columns or
whatever UIs we want.
The ColumnView now allocates column widths first and then the individual
rows use the new layout manager which looks at the column allocations to
allocate their children.
It's a GtkListItemWidget subclass that tracks the column it belongs to
and allows the column to track it.
We also use this subclass to implement sizing support so columns share
the same size and get resized in sync.
This splits GtkListItem into 2 parts:
1. GtkListItem
This is purely a GObject with public API for developers who want to
populate lists. There is no chance to cause conflict with GtkWidget
properties that the list implementation assumed control over and
defines a clear boundary.
2. GtkListItemWidget
The widget part of the listitem. This is not only fully in control of
the list machinery, the machinery can also use different widget
implementations for different list widgets like I inted to for
GtkColumnView.
This reverts commit 6a164ab306dad9096bde736c907494c71086d3c4.
The function was awkward and we now have only one caller again, so we
can fold it back into it.
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.
Also refactor the whole list item management yet again.
Now, list item APIs doesn't have bind/unbind functions anymore, but only
property setters.
The item factory is the only one doing the binding.
As before, the item manager manages when items need to be bound.
It's all stubs for now, but here's the basic ideas about what
this object is supposed to do:
(1) It's supposed to be handling all the child GtkWidgets that are
used by the listview, so that the listview can concern
itself with how many items it needs and where to put them.
(2) It's meant to do the caching of widgets that are not (currently)
used.
(3) It's meant to track items that remain in the model across
items-changed emissions and just change position.
(2) It's code that can be shared between listview and potential
other widgets like a GridView.
It's also free to assume that the number of items it's supposed to
manage doesn't grow too much, so it's free to use O(N) algorithms.
Thisis the abstraction I intend to use for creating widgets and binding
them to the item out of the listview.
For now this is a very dumb wrapper around the functions that exist in
the API.
But it leaves the freedom to turn this into public API, make an
interface out of it and most of all write different implementations, in
particular one that uses GtkBuilder.
This is an enum that we're gonna use soon and it's worth introducing as a
separate commit.
The intention is to have meaningful names for return values in
comparison functions.
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.
Without a way to create events, there is no point
in allowing gdk_display_put_event to be used from
the outside. And little good can come out of using
the other apis, so just make them all private.
With this, the expand_content_files list has been
completely converted to markdown files. Whats left
in content_files is man pages, and a few special
cases.
Arrange for files named section-foo.md to be turned
into docbook sections, while others get turned into
chapters. This is necessary to allow including such
content in chapters, since chapters in docbook don't
nest.
As part of the conversion, give up on including
sources files from the examples directory, and
instead include the content directly. All include
mechanisms add complications. They were already
complicated with xml, and markdown is not making
things easier.
We already did that for fragments, and if you
make changes to these example sources, you
probably need to revise the surrounding text
anyway.
Use pandoc to convert freestanding markdown files to docbook for
inclusion in the generated docs, and use bits and pieces of
gtk-doc code to continue expanding typical gtk-doc abbreviations.
The new tool for markdown -> docbook is a python script called
gtk-markdown-to-docbook.
The markdown dialect is specified via a list of pandoc extension
in gtk-markdown-to-docbook. It includes header annocations,
definition lists and tables, among other things.
This commit converts the 3 overview chapters (drawing, input
handling and actions) and the migration guide to markdown
syntax. Other files that are still listed in content_files
can be converted later.
This commit adds a pandoc dependency.
Drop apis and code related to appmenus from
both GtkApplication and GtkApplicationWindow.
We still keep the menubar support, since it
is needed for system integration on OS X.
Fixes: #2731
We are using floating point for coordinates
everywhere now, so be consistent here.
This commit also changes the implementation of
gtk_fixed_get_child_position to work with
non-translation child transforms.
Nested main loops are bad, as they introduce layers of complexity caused
by the potential re-entrancy in the case of multiple event sources, like
IPC, threads, etc. Additionally, the programming model they provide—stop
the world while spinning a new loop—does not conform to the event-driven
model employed by GTK.
Nested main loops are bad, as they introduce layers of complexity caused
by the potential re-entrancy in the case of multiple event sources, like
IPC, threads, etc. Additionally, the programming model they provide—stop
the world while spinning a new loop—does not conform to the event-driven
model employed by GTK.
This commit is porting GtkPaned to be derived
from GtkWidget instead of GtkContainer, while adding
start-child and end-child properties. The existing
properties are renamed to follow the start/end naming
scheme, and we add proper getters and setters.
Update all users.
See #2719
Redo this series of examples from 2013, and adapt it to modern
way of doing things. The biggest differences are that we use
a headerbar right from the start, and don't mention the app
menu.
Fixes: #2730
Add back a property that determines whether an individual
widget will accept focus or not. :can-focus prevents the
focus from ever entering the entire widget hierarchy
below a widget, and :focusable just determines if grabbing
the focus to the widget itself will succeed.
See #2686
