posted by Eugenia Loli on Fri 19th Dec 2003 02:24 UTC

"Owen Taylor interview, Page 2"
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.

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