Today we are very happy to feature an interview with Red Hat engineer Owen Taylor. Owen is the project leader of the GTK+ multi-platform toolkit, also known for his contributions on Pango. It is also important to note that a few days ago he received the highest number of votes for the Gnome Board of Directors elections. In the following Q&A we discuss about the features on GTK+ 2.6 and beyond, RAD tools, performance, GL and other widgets, GTK# and lots more!
1. Which are the main new features users and developers will enjoy with the release of GTK+ 2.4? Are editable toolbars going to be in?
Owen Taylor: Important new features in GTK+-2.4 include:
– The new file selector widget, GtkFileChooser. We expect to have a much-improved user interface as compared to the old file selector, but even more importantly, the internal design is cleaner and more encapsulated. That allows us to continue improving the user interface in the future, something that was never possible with the old fileselector. The other neat feature we have with this new widget is tight integration with gnome-vfs for GTK+ applications running within GNOME. There will be a consistent view of available filesystems between GTK+ and Nautilus.
– A new dropdown widget, GtkComboBox. It handles both editable dropdowns and non-editable dropdowns; in previous versions of GTK+, we had two different widgets with different programmer and user interfaces.
– A standard way of doing completion in text entry widgets.
– A new menu and toolbar API which is action-based, meaning that the programmer just implements a callback for the “Save” action, rather than having to worry about separate callbacks for menu and toolbar items. If you disable the “Save” action, then both the menu and toolbar item are automatically disabled.
I’m probably forgetting something else important… the support for editable toolbars is there, and the GTK+-2.4 version Epiphany has editable toolbars, but GTK+-2.4 itself won’t contain the user interface for editing toolbars or the support for saving the results of editing. We didn’t feel there was enough consensus and existing practice to standardize that at this point.
2. Which are the main features planned to be done on GTK+ 2.6/3.0? Any new widgets on the plan? (e.g. like OSX’s drawers)
Owen Taylor: Many of the ideas that have been thrown out for future versions of GTK+ can be found here.
It’s hard to say exactly what will make GTK+-2.6, though I think dock, toolbar editor, and wizard (druid) widgets are likely. An exciting future direction for GTK+ is switching to Cairo as our primary rendering API, but that’s more likely a GTK+-2.8 feature, than a GTK+-2.6 feature.
I’d like to see someone prototype out OS-X style drawers and use them in an application or two before we considered them for inclusion in GTK+. We generally try to make sure that we have a pretty good idea how a feature should work before we include it in GTK+.
3. How easy or difficult would be to tweak GTK+ to use the compositing/3D acceleration as designed by freedesktop.org’s X server?
Owen Taylor: Improvements that are available in Keith Packard’s new design can basically be divided into three categories:
– Improvements that automatically work for all X apps, such as the elimination of redraws by saving the contents of all toplevel windows.
– Improvements that need toolkit integration, such as completely smooth opaque resizing of windows. GTK+ provides enough of an abstraction between the application and the windowing system so that it’s very easy to do this type of thing inside GTK+ and have it work for existing applications.
– Improvements that actually enhance the set of capabilities available to applications, such as allowing applications to have partially transparent windows. By definition this will require extensions to the GTK+ API. It’s probably most natural to do that within the framework of switching to Cairo as our rendering API.
4. GTK+ gives this “heavy” feeling to many users, some of its redraws are pretty slow and they give an impression of the Gnome apps to be slow, just
as an example. Is there a performance issue on GTK+? How’s speed compared to Qt or GTK+ 1.x and how much profiling and when was done so far?
Owen Taylor: One of the most interesting projects that I’d like to see someone work on is quantification of such a “heavy” feeling. Without actual numbers, work on performance is basically just blind guessing. There is also a large danger of placebo effects… if you tell someone that something is faster now, they’ll see it as faster.
But if we can document that the time between pressing the mouse button on a menu item and the time for the submenu to pop up and fully paint is 20ms, then we can start looking at exactly what is being done in the 20ms, and when we make changes, we can verify that they actually improved the situation.
I don’t have numbers to compare to Qt or GTK+-1.x, though I can tell you that GTK+-2.x *is* slower than GTK+-1.2 in many areas. Since GTK+-2.x has much more power than GTK+-1.2 and draws text and graphics in a fancier fashion, it will pretty much inevitably be slower unless the authors of GTK+-1.2 were idiots. As one of those authors, I’d like to think that they weren’t :-).
Profiling and performance work has been an ongoing task on GTK+ since before version 1.0. Usually when we turn to that task, we quickly find a few forehead-slapping mistakes that are easy to fix, and then it gets a lot harder to make progress.
A big bottleneck right now in GTK+ performance is the poor performance of the RENDER extension drawing anti-aliased text. Even without hardware acceleration, it could be tens of times faster than it is now. I’m hopeful that the X server work currently ongoing on freedesktop.org will result in that being fixed.
5. There are many those who feel that Gnome lacks a good RAD tool, as Glade has a few usability and other shortcomings (e.g. the need of libglade instead of real code generation, slower resulted performance). What are the steps the GTK+ project would take to offer a better RAD tool today? Shouldn’t be offering powerful related tools be part of the project’s scope for its developers to use?
Owen Taylor: Libglade is a much better way to do user interfaces than code generation. I understand that Microsoft has come to a similar conclusion and will be introducing run-time loading of XML user-interface descriptions in Longhorn. I’ve never seen libglade be a bottleneck in GTK+ application performance.
In general, there’s no reason for the “GTK+ project” to step on the toes of those already working on IDE’s and rapid-application development tools. We’re plenty busy as it is, and there seems to be good progress on new versions of tools such as Anjuta and Glade.
We will likely be introducing something similar to libglade in the GTK+ core in the future, since it’s only a small amount of code, and making it a separate dependency for applications just makes things harder on people.
6. In your opinion, what is the biggest architectural flaw on GTK+ today and how would you go around it? On the same theme, what is GTK+ best feature?
Owen Taylor: If I had to name one architectural flaw in GTK+ it would be the extensive use of pixel units in the API. Resolutions for desktop displays have slowly crept up from around 70dpi to around 120dpi over the last 15 years. Even with that range, you can get away with a fixed pixel spacing and not have things look that bad. But at some point, you need to scale padding with font size and icon size.
From the point of view of the API, there are some tricks we can play to introduce scalable units in GTK+; we could, for instance, reuse the high bits of dimensions as a unit. That is, if you have a 32-bit integer parameter, you divide it as:
xxxxxxyy yyyyyyyy yyyyyyyy yyyyyyyy
Unit ——- 26-bits of size —–
As long as nobody specified 70 million pixels of padding in old code, you maintain a high degree of compatibility because old code always had those high bits as zero. Actually implementing something like this for all the hundreds of places where GTK+ takes pixel units is, of course, a huge amount of work.
The strength of GTK+ lies in its depth, flexibility, and completeness, rather than in any one single feature. But if I had to pick out one single aspect where I think it excels, I’d probably go for the comprehensive support for language bindings.
7. How do you feel about bindings? Do you believe that more language bindings should be offered by default together with the rest of the Gnome tarballs?
Owen Taylor: I love language bindings. In fact, to my knowledge I was the first person to publically mention working on a language binding for GTK+.
In terms of providing language bindings with the GNOME tarballs, I think that really should be driven by what we are using to write the core GNOME applications. I don’t think making people compile language bindings that we aren’t using in applications makes a lot of sense.
Murray Cumming has recently been working on a project to provide a coordinated language bindings release as an adjunct to the GNOME release, which I think is a good thing.
8. What is your opinion on Mono and GTK#? How would you feel if GTK# becomes and language of choice (instead of C) for most Gnome developers in the future?
Owen Taylor: C# is a nice language. Not the only nice language, but a nice language. What I’ve seen of GTK# looks promising, though I haven’t had nearly as much time to look at it as I’d like. I think whether C# is suitable for use as a standard language within GNOME really depends as much on political issues as on technical ones. Any sort of commitment to a language requires consideration of who controls the language and what assurances we have that we won’t get adversely affected by that control in the future.
A roadmap for this area was one of the items on my GNOME foundation board campaign statement and something that I definitely intend to push in the future.
9. Are there plans to make the theming engine more flexible? Most advanced things require an engine currently. An effort to bring this mockup to life resulted in a… mediocre-looking theme with issues. Also, there are some themes that are extremely slow for some reason (especially when moving scrollbars they get bad redraws with some bitmap themes). Any plans for fixing these issues?
Owen Taylor: Theme engines are pretty flexible currently, but require quite a bit of detailed knowledge of GTK+ to get right. Looking at the screenshot, the only things I see that look actually infeasible are the treatment of menus and the way that the tree connections are drawn. Everything thing else should be possible to do pretty much pixel-pixel as you’ve drawn it.
Extremely slow themes generally means buggy themes. The default GTK+ look is done as a theme internally and there’s no reason that a theme shouldn’t perform just as well.
Generally, the only way that we could make theme engines flexible enough to do something like the snake-like menu highlights would be to allow the theme-engine to replace large amounts of GTK+, which would have disastrous effects on the ease of writing a theme on and on future compatibility. So, instead, in similar cases, what we’ve done is added an option to the core of GTK+ and allowed themes to turn it on. An example of that is the ability of themes to control the placement of arrows around scrollbars.
So, I’d encourage interested programmers to try implementing such an option in GTK+. Once we have a prototype patch, people can try it out, see how it work in practice, and then we can consider making it a standard part of GTK+.
10. Any plans to incorporate the OpenGL widget/views (gtkglarea 2) into the main tree?
Owen Taylor: Some sort of GL support is quite likely to make GTK+-2.6, though the details haven’t been worked out yet. The currently maintained GL support for GTK+ is Naofumi Yasufuku’s GtkGLExt, which is quite nice in a lot of ways, though I’d like to see something that integrates a little more naturally into GDK. Some notes on the integration by Mathieu Lacage can be found here.
It may be that GL support for the Cairo-based version of GTK+ will be extremely easy to implement; one thing that people are experimenting with currently is making Cairo target GL directly. If that is the standard way of running on X, then all GTK+ has to do is provide a passthrough to allow the application to access the underlying GL objects.