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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list