RFC: new features

[Benjamin Otte <otte gnome org>]

One thing I've been wondering about is what features GTK is missing.
This is mostly about developer-visible APIs, ie new widgets, and not
about internal changes. I have some ideas from IRC discussions, mails
and applications, but of course there might be big things I'm missing.

So personally, I consider a feature useful for inclusion in GTK if:
A) ... it is useful to a lot of people
This explains itself.
B) ... it belongs into the "widget toolkit" realm
There's a bunch of functionality that either belongs into a lower
layer (see all the things in glib for examples of that) or into a
higher layer (an example would be Webkit).
C) ... it is provided by other toolkits successfully
If there is another toolkit that has this functionality and people use
it, that's a good indicator that people may want to use a similar
feature with GTK. Of course, the opposite is also true: If other
toolkits provide the feature and it sucks or nobody uses it, there's a
high chance that it really is a bad idea.
One important note here: I do consider the web (aka HTML5) a toolkit.
D) ... it's hard to get right
Some features look very simple, but are incredibly hard to get right.
An example here is text layout. It's not just hard to get right, it
also has a lot of corner cases in languages that developers do not
speak themselves so will have no clue about.
E) ... getting it right can have lots of benefits
Some things can
F) ... it is portable
Some features are very specific to a certain platform and cannot be
easily ported - such features are usually best kept in per-platform
libraries and not shipped in the default. Of course, we always have
exceptions, just look at GtkSocket and GtkPlug.
G) ... inclusion has a benefit to GTK
Again, Webkit is a good example: Including it in GTK would certainly
be a good thing to do, but having GTK link against a browser engine
would complicate the build process, increase the size of libgtk and
add a lot of code to maintain. So it's rather beneficial to have it
not part of GTK.

And with these caveats, I'll go on and list the features and my
personal opinions about them - why they are not yet part of GTK and
why they should or should not be. As always, feel free to disagree or
list more features that you think might be worthwhile.

DOCK
http://developer.gnome.org/gdl/stable/gdl-main.html
A docking widget is something I've always missed in GTK, in particular
one with powerful reordering, and UI adaptation capabilities. The main
reason this has never happened is that it's a feature for huge
applications with lots of toolboxes, like the GIMP, Inkscape or
Anjuta. And those applications usually go their own way instead of
converging on a common UI. Also, a dock is often a bad answer in UI
design if your application is not complex. And if it's included as a
general widget in GTK, it might encourage too many people to use it.
And then we're stuck with bad UIs everywhere.
So my feel is that a docking widget is unlikely unless the big players
cooperate on developing one and propose it for inclusion.

CANVAS
https://live.gnome.org/ProjectRidley/CanvasOverview
For a canvas pretty much the same reasons apply that apply for the
dock: The people that really need one are the people writing complex
applications and tose people have very different needs, so they end up
writing their own. What makes this worse though is that GNOME 2 had a
canvas and nobody used it (or better: everybody forked it). And then
there were a lot more canvas libraries, but they didn't go anywhere
either.
Additionally, GTK is moving to being a canvas itself. So there is very
little push from inside GTK to add an extra Canvas widget, but more
push to make GTK better internally to be a canvas.
My feel is that a separate canvas widget will never happen. But GTK
will probably be good enough to not require a separate canvas anymore.

OPENGL
http://projects.gnome.org/gtkglext/
A lot of people would like to embed existing OpenGL solutions into
GTK. As far as I can see it's one of the most-requested features from
developers. But OpenGL is a very bad library for integrating with. And
a lot of the OpenGL implementations are pretty bad (and the libgl
writers than blame that on the GPUs. So nobody wants to support and
maintain a binding of GTK to OpenGL, in particular because there is
not just one binding to maintain but one for each platform/GL
implementation.
I would really like to see this feature happen, but the lack of
commitment from developers seems to not make this happen any time
soon.

VIDEO PLAYER
One of the things that is really hard to do is getting a video player
working. It's doable with GStreamer if all you care about is
displaying the video in a rectangular area of your screen, but once
you want to overlay widgets, put videos in cell renderers or do other
interesting things, stuff gets hairy. Looking at the existing
solutions, Totem has switched to Clutter and Epiphany's multimedia
support failed me spectacularly on http://cuttherope.ie/ today. It's
certainly not like in Flash or even Firefox where videos just work
everywhere.
On the other hand, integration of video playback into toolkits has
been quite a bumpy in other toolkits. Clutter-Gst had a bumpy road,
Phonon went in and out of Qt and DirectShow has had quite a few
iterations, too. Also, the question of what API to provide on the
toolkit level is an interesting one, too. If we look at the GNOME
applications that currently make use of GStreamer, we have a sound
recorder, a video player, a volume control, a webcam application and a
videochat tool. There's not much overlap there that I can see.
While I would like to see something that makes video easy, I'm not
entirely sure how it would look. In particular, I can't see what
features an API would or would not provide, but still be easy,
featureful enough and portable. But I'd certainly be very interested
in having video support in the toolkit.

AUDIO SUPPORT
The current audio support in GTK is a bit lackluster with just
gtk_widget_error_bell(). Sound events are provided with a loadable
module in the form of libcanberra, but that one feels like an ugly
stepchild - it's using signal emission hooks and seems rather poorly
maintained. But then, not a lot of people seem to care about sound
events -at least there's not been a lot of movement in that region for
a long time. Otherwise we'd probably have seen a push to establish
proper sound event support inside GTK. Nonetheless, it'd be nice if
the important sounds that people actually do care about (like alarms)
could actually use a framework inside GTK.
My verdict is that this again is a desirable feature but most likely
not going to happen unless people show up and implement support for
it.

PLOTS
This is my personal pet peeve. I often have something I'd like to
quickly plot in GTK, but it always ends up being more complicated then
I thought, so I either stare at text or use Gnumeric to get my plots.
And all the other applications (like virt-manager or
gnome-system-monitor) that do plotting look rather crappy and their
plots don't provide a lot of features (no zooms, no tooltips with
actual values, no ability to expand or collapse certain parts).
However, is a plotting widget a useful addition to GTK? If it works
well, it would surely enable people to show lots of useful statistics
that we'd all be thankful for - collecting them is not hard after all,
but making their output useful is. I'm sure a lot of people would like
bandwidth graphs in NetworkManager, page load performance graphs in
Epiphany or an interactive bootchart. Even if it's "just" the
developers using it to improve the rest of the world.
That said, such a widget would need a simple interface - both in API
and UI, and I'm not seeing anybody working on that. But I'd be very
interested.

MAPS
http://projects.gnome.org/libchamplain/
Libchamplain exists, but it's uptake inside GNOME has been very
lackluster. The timezone selection tool still uses its own map, as
does evolution. And photo editing tools and other apps often don't
show maps at all, but just coordinates. However, a well-done maps
widget would - just like a plot widget, improve visuals in a lot of
places.
That said, I have no idea if it is too specific a widget for GTK.

So there you go.

Benjamin