summaryrefslogtreecommitdiff
path: root/gtk/gtklistitemfactoryprivate.h
Commit message (Collapse)AuthorAgeFilesLines
* Convert headers to #pragma onceMatthias Clasen2023-03-311-3/+1
| | | | The conversion was done by guard2one.
* listitemfactory: Make this callback-basedBenjamin Otte2022-06-281-15/+26
| | | | | | | | This way, we no longer prescribe the use of either GtkListItem or GtkListItemWidget. This means we can use it in other places, such as for custom section header objects or with my Canvas ideas.
* listitemfactory: SimplifyBenjamin Otte2020-05-301-5/+7
| | | | | | | | Instead of 6 vfuncs, we now have 3 and rely on the factory keeping track of what it needs to do. We're doing lots of dancing from one object to another here, but this will hopefully get simpler with further commits.
* listitemfactory: Reorganize vfuncsBenjamin Otte2020-05-301-28/+4
| | | | | Instead of bind/rebind/update/unbind, we now just have update, and the factories get to interpret that in the way they want.
* listview: Expose GtkListItemFactory APIsBenjamin Otte2020-05-301-15/+4
| | | | | | | | | | | 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.
* listitemfactory: Split implementation outBenjamin Otte2020-05-301-10/+0
| | | | | | .. into gtkfunctionslistitemfactory.c Now we can add a different implmenetation.
* listitemfactory: vfuncifyBenjamin Otte2020-05-301-0/+28
| | | | No functional changes other than a new indirection.
* listitemfactory: Sanitize APIsBenjamin Otte2020-05-301-0/+22
| | | | | | | | | | | | Make sure the APIs follow a predictable path: setup bind rebind/update (0-N times) unbind teardown This is the first step towards providing multiple different factories.
* listitem: Add a press gesture to select the itemBenjamin Otte2020-05-301-1/+2
| | | | | | This is implemented by using actions, which are a neat trick to get to allow the ListItem to call functions on the ListView without actually needing to be aware of it.
* listview: Add selection properties to ListItemBenjamin Otte2020-05-301-2/+4
| | | | | This just brings the infrastructure into place, we're not using the properties yet.
* listview: Change how binding is doneBenjamin Otte2020-05-301-2/+2
| | | | | | | | | | | We now don't let the functions create widgets for the item from the listmodel, instead we hand out a GtkListItem for them to add a widget to. GtkListItems are created in advance and can only be filled in by the binding code by gtk_container_add()ing a widget. However, they are GObjects, so they can provide properties that the binding code can make use of - either via notify signals or GBinding.
* listitem: Add gtk_list_item_get_position()Benjamin Otte2020-05-301-0/+4
| | | | | | | | | | 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.
* listview: Add GtkListItemBenjamin Otte2020-05-301-2/+5
| | | | | GtkListItem is a generic row widget that is supposed to replace GtkListBoxRow and GtkFlowBoxChild.
* listview: Introduce GtkListItemFactoryBenjamin Otte2020-05-301-0/+54
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.
View Lorry Controller Status