The ideas/plans posted in the Gtk 3.0 Roadmap sound good and relevant in overall. Some of them will really help Gtk to provide stuff other toolkits are doing/working on and thus keep gtk relevant in the future.

However, what I’m really missing from the roadmap is clear support for the different platforms where Gtk is being used.

Currently gtk is quite big library. And most of that is very desktop oriented. There’s nothing bad in that, as such, but it means that gtk is not able to be mobile oriented at the same time.

To solve this, I’d like to see the “point-zero / API break” release to be taken one step further: to divide Gtk into (sub-)packages, which applications can use in opt-in basis. Here’s a layman’s suggestion to the division:

gtk-core — all non-widget stuff that is needed for widgets to work. Additionally, the bare essentials of the most generic widgets: Label, slider, entry, textarea, button, ?? (yes, I’m seriously thinking of not even having GtkTreeview and IconView here, because they have evolved to be SO complex right now).

gtk-desktop — all stuff that is not in core, including the rest of the widgets

gtk-mobile — (new) only widgets relevant to mobile people? Maybe towards some kind of set similar to what hildon is in maemo 5?
http://maemo.org/api_refs/5.0/alpha/libhildon

gtk-???

The idea in the division (obviously) would be that you could include e.g. gtk-core while not having to deal with the whole package of gtk-desktop. Or even create your own widget library (a bit similar idea what hildon is doing) and only use gtk as the foundation for those widgets.

I think this kind of approach (if it makes technically any sense) would help speeding up the experimentation and enhancement of gtk towards multiple platforms, while not forcing gtk to throw out or replace any of the stuff it currently has (and of which much remains to be useful for e.g. desktop platform).

I see a list of features, but it doesn’t communicate the problem it solves, the goal it contributes towards, nor the inter-relationships of the changes.

Perhaps this isn’t the document to communicate the larger vision, but that vision should at least be summarized, cross referenced, and the document aligned in part with that so people can understand the importance of each contribution (and which contributions, although important, are not core features but rather supporting libraries)

I read through the list and it looked as if rapicorn & clutter are *the* tools for the GTK canvas.
Nothing like GTKCanvas *canvas = gtk_create_canvas(window, WITH_GL, background, DEFAULT_PEN); though :(