===== 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 (parentchild 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.