GTK+ Hackfest Spring 2013

Cambridge, MA, April 19 - 24, 2013

Relevant GNOME teams

The GTK+ team and designers

Description

The codename for this meeting has been "EggListBox hackfest". We want to work on a bunch of new widgets that have been developed for new GNOME3-style applications, and get them ready to be integrated into GTK+ proper.

The core hackfest, is Friday, April 19, and Saturday, April 20. Then we take a day "off" on sunday and have a three day followup hackfest where we look at what's left after the first few days. The final day is probably more like a half day as people need to leave and stuff.

Venue

Update: Due to a city-wide 'shelter-in-place' order, the OLPC office is closed on February 19. We will try meet there again on Saturday. Be sure to bring a photo ID, so the guard can let us in based on the attendance list.

Accommodation

Some people have rooms at the Hampton Inn Boston/Cambridge which seems reasonably cheap. Crashing on somebody's couch is also a possibility.

Open Issues

Listing some open issue that we can discuss at the hackfest, please add more if you have any ideas:

EggListBox

Scalability: Whats the requirements? How well do we scale now? What are the bottlenecks?

GtkStateFlags propagation: If a row is selected, how is that propagated. We want a child label in a selected row to be white to match the selected bg, but we don't want to set selected on e.g. a child checkbox because then it looks "checked".

DECISION: We think it makes sense for state to not propagate, but this is a largeish change in CSS behaviour which need theme changes. We want to test this to see how it will work out.

Row containers: To allow proper state on a row (i.e. SELECTED or PRELIGHT) we want to have some kind of object for each row that can carry this state. We don't do this right now, and it means we can't set a SELECTED flag except in the _draw() function, and thus it will not propagate to e.g. a child label. This is also problematic for a11y. One solution is to have a custom row widget (container) type and ensure all children are instances of this, another is Benjamins work on Actors which are non-widgets that still are part of rendering hierarchy.

DECISION: There will be a public GtkWidget row/item type that will always be used as the children of a listbox.

Allow theming of row borders

API: Need review. The set_separator_funcs API is horrid and everyone gets it wrong.

Infinite Scrolling: Some kind of callback when you reach the end to add more items.

Model/View: Do we want some kind of data model level that can drive a ListBox?