Gtk+ 3 Roadmap Draft

[Tim Janik <timj gtk org>]

Hello Gtk+ Development Community.

The need for a Gtk+ 3.0 roadmap has been discussed during several
Gtk+ team IRC meetings, at conferences and on other opportunities.

So a few months ago, we've set down to collect the input from so
many people who have contributed feature requests, ideas, improvment
suggestions and procedure suggestions to this. An initial draft
was then sent to the core team for initial comments.

Unfortunately for business and personal reasons, I've not had a
chance to stay on the topic for quite a long while. But recently
Cody Russell gave me some friendly kicks in the right direction
and even threatened to wikify the roadmap draft to open it up
for community participation. ;)

I think that's exactly what needs to happen with this. This roadmap
draft is in no way finalized, it's basically a conglomerate of the
various inputs and feedback the core team has been getting so far.

I'd like to particularly thank Stormy and Dave Neary for good
discussions and suggestions on the post-draft process.

Discussion of the roadmap, additions/changes/deletions and
reclassifications of the contents are probably best done in
several phases as outlined in the prelude.

The source text is attached and for reference provided online
next to an html version:
	http://testbit.eu/~timj/blogstuff/GtkRoadmap3Draft2.html
	http://testbit.eu/~timj/blogstuff/GtkRoadmap3Draft2.txt

I sincerely hope this is helpful for everyone. ;)

---
ciaoTJ

===== Gtk+ 3 Roadmap Draft2 =====



==== 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: http://live.gnome.org/action/edit/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)~~

* 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
    [[http://msdn.microsoft.com/en-us/library/ms682521.aspx | QueryInterface() COM API]],
    [[http://library.gnome.org/devel/libbonobo/stable/libbonobo-bonobo-object.html#bonobo-object-query-interface | Bonobo]] and
    [[http://rapicorn.org/rdocu-rapicorn/utilities.hh.html | 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 [[http://live.gnome.org/GtkTasks GtkTasks]] page.
  ~~(For 3.0 preparation, we already have: http://live.gnome.org/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.