Gtk+ 3 Roadmap Draft2

From http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg00048.html

Prelude

The suggested plan is to work on this and publicize it in multiple steps:

• The Gtk+ core team produces an initial version (draft1). [TimJ collects feedback via email during the first core team email round and integrates draft2 for gtk-devel-list.]
• The draft is reviewed, extended and completed to produce a real roadmap with the gtk-devel-list community. [Probably best done by letting people edit a live.gnome.org wiki page after announcing change intentions on the mailing list.]
• An "official" Gtk+ project roadmap is put up on the web, announced in various channels and feedback is requested from other projects and companies of the GNOME/free software hemisphere for a period of 1-2 months.
• Feedback and change requests are worked into the official roadmap after discussions on gtk-devel-list.
• A team is formed that maintains a list of contributors and volunteers for particular tasks and keeps track of the roadmap progress.

Feedback on the exact progress is of course welcomed as well.

Introduction

The Gtk+ team is forming a roadmap to structure the development process of the Gtk+-3.0 release and to open up the involved decision making progress. Since development on the project depends to a large extend on community contributions, we cannot provide deadlines, but will use priority based classifications instead. [Stormy nicely describes the tension between time, features and contributors here: http://www.stormyscorner.com/2008/09/as-open-source.html ]

Items are classified according to:

1. Items we believe the core team will have completed by 3.0.
2. Community contributions that are feasible to achieve for 3.0.
3. Items that seem unlikely to be completed for 3.0 or are specifically planed for 3.x follow up releases.

Features planned for 3.0

These features are meant to be completed and integrated with the release of Gtk+ 3.0. The core team will do its best to achieve completion, but contributions are also very welcome.

• Full offscreen rendering, probably completed in 2.x. This is needed for animations and effects beyond the classic widget boundaries.
• Remove all public structure fields so the API is defined only in terms of function entry points.

• Introduce new widget creation means that fix currently problematic widget property defaults like widget visibility. [A wiki page exists, which considers table property changes: GTK+/PropertyDefaults ]

• Eliminate the need for implementing realize/unrealize, map/unmap, style_set and more, depending on how much offscreen rendering allows for this.

• Implement a new base class widget for scrollable widgets that could help to simplify the implementation of widgets like text-view, scrolled window, tree-view. [The Beast project has something resembling this here: http://beast.gtk.org/rdocu-gxk/gxkscrollcanvas.h.html ]

• Resolution independence, this allows free scaling of UIs, including fonts, pixmaps and spacing/padding. [David Zeuthen already started to work on this: http://blog.fubar.dk/?p=102 Resolution Independent GTK+. In a corresponding email thread, David explains how the features could be split up according to 2.x and 3.x dependencies: http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00044.html. Tracking bug: 546711

• Anything from the current 2.16 list that didn't make it in time:
  • support for icons in entries
  • better handling of invisible characters
  • flippable boxes, separators, etc
  • resolution independence/font scaling
  • complete offscreen window support
  • extended layout (width-for-height)
  • a tool palette widget
  • a simple list API
• Simplified DnD API, work on this is going on in the tree-view already.
• Add simple transparency API for widgets (should work by means of offscreen rendering if XComposite isn't available).
• Allow themable RGBA backgrounds for widgets.

Contributor features for 3.0

Implementation and/or completion of these features depends on community/third-party contributions to Gtk+. We'd like to see them integrated, but can't implement them with the core team, so it's best understood as a list of suggestions for people who want to contribute to Gtk+ development.

• Create an animatable container with pluggable layout algorithms and pluggable transition algorithms.
• Physics features in the UI:
  • kinetic scrolling, magnetism, friction, bounces, stretching
  • fading, blending, shadows and other optical effects
  • This depends on an animatable container
• Easier layouting, e.g. by letting EXPAND default to false and introducing a "spread" flag like Rapicorn has it. (It essentially forces all parent widgets to EXPAND automatically.)
• Themable padding.
• Add "label styles" a la Mac; relative to base font. The Mac defines label styles like "system font", "big system font", "header font", etc. It might be nice to have label constructors for this like gtk_label_big_system_font_new(). The styles would be themable. Pango markup also covers bits of this, but misses the themability. All in all, this might simplify dialog creation as you need headings for groups of UI elements, etc.
• High-level way to emphasize text, to properly support non-Latin languages. In Latin languages, you can use italics to emphasize something, italics do not necessarily have to work for non-Latin languages. Having a high-level way to mark a piece of text as "to be emphasized" will help here. There are probably more likewise i18n improvements that can be made here.
• Add automatic tests for layout functionality.
• Add a spinning progress widget to Gtk+ ("Throbber").
• Generalize event handling, so it's not as bound to X11 concepts. This could simplify offscreen window event simulations and implementations of non-X11 backends. Also interfacing with custom event sources (like widgets embedded in clutter or Rapicorn) will then become feasible.

• Separation of widget grouping (parent<->child relationship) and from geometric layout.

• Full support for MPX and multitouch devices. Also needs event system concept changes.
• Making it easier to create widgets.
  • Automatically flippable widgets (horizontal/vertical).

  • Have a high-level widget to create widgets with. Maybe a template system? Have a high-level widget base class on top of GtkWidget, a scrollable widget base class on top of that again. Implement your own widget by subclassing one of these.

  • Have a way to "draw a button" in your custom widget.

• Provide third-party code analysis and migration tools that aid porting and assist in writing best-practices code. [Richard Hult already started work on code migration tools: http://people.imendio.com/richard/archives/2008/08/ ]

Wishlist items for 3.x

The following features would be nice to have but depend on contributor help and are probably going to arrive only in releases after 3.0.

• Revamp/rewrite the entire theming system.
• Allow usage of projective transformations in the toolkit (when suported by the hardware, use 2D fallbacks instead), possibly via clutter integration (to utilize GL features) or adding 3D capabilities into Cairo (like extending the transformation matrices).

• Micro widgets, i.e. small and very simple widgets that can be used for composition of bigger complex ones. [This approach proves very successful in Rapicorn: http://testbit.eu/wiki/Rapicorn-Tech-Bits#micro-widgets Rapicorn Micro Widgets ]

• Allow widget composition with UI builders. This would probably involve:

  • Adding a "query_interface() like" object API, so composite containers can integrate and "export" child widget functionality. [Existing examples for querying object interfaces are QueryInterface() COM API, Bonobo and Rapicorn::Convertible::interface ]

  • Adding a "Composite widget creation" mode to UI Builders that allows specification of interface types with names to be exported on the composite container from its children.

Progress Tracking

Several things should be done once a roadmap is finalized, it's probably best to form a team to oversee and handle the items:

• Create a Gtk+-3 feature task table, where contributors can sign up for particular work items. Could be similar to the GtkTasks page. [For 3.0 preparation, we already have: GTK+/3.0/Tasks ]

• Keep track on completion of features/tasks listed in the roadmap, so anyone is able to monitor progress.
• Publicize content on gtk.org:
  • Create a section on best practices.
  • Create a section on porting-to-3.0.
  • Add a script to porting-to-3.0 that shows/analyses use of deprecations in a given code base.
  • Create a blog about Gtk+-3, covering updates to feature list, open tasks, plans and roadmap.
• Ask and keep track of ISVs to put resources on items on the Gtk+-3 feature task table and possibly other sub projects they intend to sponsor.
• Handle and integrate requests coming in during the 1-2 month "consultation period", where we specifically request feedback and input from ISVs through Stormy, Dave and possibly other channels.
• Look into GSoC projects to implement 3.0 tasks.

Much of this can be done in parallel, and is probably best split up between Gtk+ community members.