posted by Eugenia Loli on Fri 19th Dec 2003 02:24 UTC
IconToday 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:

Owen Taylor - 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.

Table of contents
  1. "Owen Taylor interview, Page 1"
  2. "Owen Taylor interview, Page 2"
e p (0)    89 Comment(s)

Technology White Papers

See More