GTK Roadmap

Notes from the GTK+ Roadmap discussion at the 2014 Developer Experience Hackfest.

1. Fill the gaps to enable HIG-compliant apps

• Model with flowbox and listbox. Should we delay the HIG until that is ready? Probably not, because you can actually use those today. Maybe port a couple of apps to flowbox. Ryan and Lars are working on this.

• GtkNotebook replacement based on GtkStack. Needs a bit of design work for how tabs should look and feel. Would be nice for the HIG, but isn’t a blocker. Carlos will look at this.

• new GtkComboBox. We should split the widget into the different elements that currently are all merged into one. What are the use cases we want? Needs design - we need to know exactly which widgets we want and what they should be like. Nobody is currently working on this, and it is blocked on the model support for listbox.

• In-app notifications. What’s the difference with a GtkInfoBar? Permanent (infobar) vs temporary (notification). Might want to give it a different name, so it isn’t confused with other notifications - “Message Bar”, “Message Overlay”? We need to detail more about how it should behave. Lars: should this just go onto the window, since we have a titlebar there? Cosimo: ties in with a generic idea of a main view that we currently don’t have. Currently requires an overlay. Ryan: maybe it should just be an API of GtkWidget itself? Allan: we want to have the freedom of changing it in the future. Shouldn’t give you a widget probably. Cosimo to work on this.

• Help overlay. We have designs. Main blocker is getting descriptive names for every action. Ryan is not convinced that there’s a good use case for it. Nobody is working on this, currently.

• Content selection. Critical for the HIG. There’s a lot of moving parts; needs support in the views. Do the views have all the support needed for it currently? Do we want to leave it as a recommendation or should there be something in the toolkit that makes it easy to get it right? Cosimo: the latter - this ties in with the concept of a content view in GTK. Benjamin: if the view exists it should be in GtkApplicationWindow. There could be view specific actions, including whether the application is in selection mode. There’s some disagreement about whether the current interaction design is desirable - need to reach an agreement here. Designers to review the current approach. Cosimo to work on this.

• Redoing the print dialog: needs preview widget. Huge piece of work. Might magically appear in the future, but no ETA.

2. A better cross-platform story

• Target: 3.14

• Replace Raleigh with Adwaita as the default theme. This was blocked on turning Adwaita into a css-only theme, which depends on:

  • Focus ring drawing Fixed in master by Cosimo

  • Borders on menus. We could do menus with client-side shadows. Nobody signed up to work on this yet

  • librsvg (depends on gtk) - can probably be fixed
• Include icon theme in builds for other platforms - coming along. First step was to create adwaita-icon-theme.
• LRN has been doing some work on the windows theme, recently.
• Provide regular builds. not much interest from potential contributors. build machines would need to have a home somewhere. Ryan is interested in hosting a mac mini and having an automated jhbuild up to gtk.

• Reintegrate the gtk-osx fork or at least marginalize it. Ryan and Will are doing a bit of work here, although slowly.

3. Touch support

• Target: 3.14

Are our widgets going to use the gestures themselves/are we getting rid of the manual event handling?

Carlos' branch can go in as-is, but there are some desired changes:

• As much public API removed as possible. We're going to handle only touch events that way automatically, so there should be no problems with compatibility. Applications can gradually port to the new gesture system and new API can be added or made public if needed.

• Disable subclassing for now Done on the branch (Matthias)

• Needs some real world porting of complex widgets to get validation - e.g. GtkLabel, GtkEntry, GtkTextView

• Store event sequences and replay them in case there's a capture + cancel in between a sequence

Carlos will work on this

Make existing widgets usable on touch: scales, spin buttons, panes, etc. Also, touch text selection needs some improvements. Some design input needed here. No need to block on this to merge Carlos' work

Eliminate last uses of double-click

Eventually we'll also need to integrate keyboard events in the new event controller model

Still more porting work needed for this

4. A scene graph.

• Target: 3.16

Emmanuele is making progress. Blocking on two things currently:

• Depending on GL. There's a library called libepoxy we should use to avoid dlopen shenanigans. This part is going to be ready pretty soon. This gives us the ability to (portably) draw a GdkWindow on a GL surface and gives us the ability to synchronize drawing on frame clock.

• Matrix stuff (graphene), another library Emmanuele is writing.

• The actual scene graph code is mostly a cleaned up version of ClutterActor

• The first step is to get a scene drawn inside a GtkWidget

• After that we can try and get a GtkWidget inside a scene inside another GtkWidget

  • Input may be an issue in this last case

Emmanuele is working on this with a target of 3.16.

We should review the target release at GUADEC.

5. Documentation

• Continue the docs-from-gir effort
• Switch gtk-doc to using function-level docs from the gir too
• Remove C-specific information from the API docs

• https://wiki.gnome.org/Projects/GTK%2B/ReturnInDocs

• Blocker bug for this if we want to have C documentation generated through this process is getting macros in the gir too
• Rely on annotations for memory management and life-cycle information
• Redo the developer.gnome.org website
  • Markdown is working well so far - means that docbook is no longer need
  • Tricky part here is cross referencing between websites.
  • Alberto is helping with a proof-of-concept for a new website. will need a volunteer who knows html/js
• Need to decide on format for documentation
• Need to build the docs on the gnome servers

6. Closer ties with glade

• Target: 3.14

• Goal: all new widgets and features to be supported in glade at the time of first release
• Difficult to come up with actionable items here. need to talk to the glade maintainers
• Consider adding a parasite-like module for live inspection and manipulation
  • Right now there's a lot of forks scattered around the interwebs

  • People agree to move it into GTK, but keep it a module for now probably. Initial prototype in the parasite2 branch 729566. Matthias is working on this

7. Cleanups in preparation for GTK+4

• Target: Incremental

• Deprecate GtkStatusIcon, GtkButtonBox, GtkArrow 729564

  • Needs someone to do it, can do it today
• Make dialog parents mandatory. This was not fully agreed on, Ryan wants to keep parentless dialogs working.

  • log when dialogs don't have a parent - see what cases emerge, with a view to mandate in the future Done in master (Matthias)

• GtkDialog hierarchy cleanup

• GtkButton hierarchy cleanup

  • Cleanup of our radio api will be a side-effect

  • GtkModelMenuItem and GtkModelButton are the playground for this

• Too many ways to do icons
• The big GDK cleanup (displaymanager/display/screen/monitor)
• Move root window to x11 backend
• More complete css box model compliance for widgets

• css focus rectangles Done in master (Cosimo)

• Simplify icon themes
• Kill gtkmisc (obsoleted by css padding etc)

• Integrate icons and css. See the wip/css-icons branch for initial work. Benjamin is working on this