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.
Interesting interview – but I must say, all this graphics/desktop technology goes way over my head. I know there’s lots of stuff written out there about it, but can anyone recommend a really good, comprehensible primer that explains all the different layers, terms, and technologies?
For example, I go to http://www.fresco.org, or some of the other “next-gen” graphics project sites, and it all sounds wonderful, but I don’t really get what they’re talking about!
Great interview. Covers all the major issues, and provides insight into the direction GTK+ is heading.
-Erwos
It would have been more nice, if this question was also included in the interview.
Will gtk-2.6/3 will be backward compatiable with its previous versions. unlike the problem that appeared betweek gtk-1 and gtk-2.
Possibly it won’t be, because if I am not mistaken, they will move a lot of the gnome-libs functionality into GTK+ itself so that will change a lot of things in the API, I would guess.
is why do they insist on using C for GUI development as the”standard” rather than GTKmm or pyGTK which are OO.
oo for GUIs are much nicer, and you can still link them to underlying C code if you must develop in C.
From the GTK+ FAQ:
“A 3.0 release would be the earliest point at which we would make a source and binary incompatible release.”
Eugenia, you run a good news site, but please stop fudding glade. It’s pretty clear you’ve never done any profiling of apps before, otherwise you’d have never claimed that libglade is “slow” (in fact it’s very fast relative to most startup tasks), or that generated code is better (in fact it’s usually a worse idea).
So, could you please tell us what it is you dislike so much about Glade? It’s far from perfect, but generally works pretty well and certainly beats most other solutions i’ve seen (especially win32 based ones).
Whatever I had to say on Glade, I already said it to its developer last week in an email exchange we had.
“oo for GUIs are much nicer, and you can still link them to underlying C code if you must develop in C. ”
So you can program in C++ or Python with the bindings, like you said. The question you’re asking is “why doesn’t everyone do exactly what I do?” The answer is just as simple: not everyone is like you.
You’re ignoring the history of the thing, too. When GTK+ started, C++ was badly defined. That’s why Qt, for instance, doesn’t use the STL, and does some fairly ugly things. Use immature C++ or mature C? The choice they made was not an easy one…
Quick question: do you even program?
-Erwos
I wasn’t too satisfied with his response on the performance issues. GTK 2 is clearly slower than QT, although GTK requires less memory in general (which may be part of the reason). It would be nice to start a project which would work on optimizing GTK.
yes I program. my point is that the GUI should be OO, not some OO hack like GTK+ is. OO is a nicer way to do the functions GUIs need to do. why do you think GTK+ tries to emulate OO through ugly hacks?
and you totally missed what I was saying. there is no reason NOT to use an OO library for the GUI since you can map that GUI code to any code you like for the Logic. look at what OS X does. the GUI is OO (ObjC) but you can write the program itself in C, C++, Java, or anything else APple has added support for.
what I am saying is that Gnome should use an OO widget set for its GUI because it makes it easier and cleaner to make a GUI with OO.
What this toolkit is missing is commercial support. Whom can you pay to get support if you need it?
>Whom can you pay to get support if you need it?
Red Hat, I would guess. Owen is pretty much the only one really working on GTK+ these days.
Blah, what’s OO?
His response was pretty much that he didn’t have any concrete speed data, which is a little disappointing in itself, but at least it is honest. Any comments beyond that would have been guesses and speculation which are counterproductive. His profiling suggestion is obviously the right thing to do, I (like you) just wish somebody was already working on it. Hopefully, once 2.4 is out, they can focus on the speed issue.
What I don’t understand is why you didn’t put some small code behind the old fileselector API which calls the new one. Why do we have to bear Gtk2 applications using different file selectors for the foreseeable future (until Gtk3)?
Because the API is completely incompatible. Apps using the old file selector cannot in any way be mapped to the new file selector. The entire API *had* to be changed just to support a new UI; the API for the old file selector is abhorrent. Many apps directly modify the old file selector dialog in order to customize it. This, along with other issues, makes it absolutely impossible to wrap the new file selector with the old API and have it actually work for more than 30% of apps.
If you want apps to use the new file selector, help port them to GTK+ 2.4.
Bad code encapsulation, probably.
That is what happens when you hack OO in C, and make even a small mistake (if it’s not the issue, ok, sorry).
Think about it: Qt and KDE have used the exact same file dialog API since 1997, and had no need to change it. There must be some reason for that.
What “people” have a problem with libglade? I have yet to run into one. The only one I ever see complaining about it is you Eugenia. Any particular reason? Why don’t you site examples from the GTK+ applications you have written? Exactly.
I am not the only one, read our previous gnome article and read the comments there for more.
OO stands for object oriented. Langues such as Java, C++, and python (haven’t used it in a while but I think it’s OO
) are object oriented.
For nontrivial GUI is OO a better choice. But GTK+ is about building an infrastructure not the apps. If you prefer OO (like me) then use GTKmm, Inti, wxWindow, java-gnome, PythonGTK, GTK#, …
That is what happens when you hack OO in C, and make even a small mistake (if it’s not the issue, ok, sorry).
Err, no. Why don’t you actually learn what you’re talking about, and then talk?
The old GTK file selector API was simply bad. Making something OO does not magically make it good, or ever better (i’ve seen some APIs that look like they were put through the backhoe after being objectified). Often it does, but not always.
The old API was basically object oriented anyway, it simply wasn’t very powerful and was badly designed. The new one is not badly designed.
The KDE/Qt file picker is basically a clone of the Windows one, nothing particularly radical there. Parts of the KDE/Qt API were bad, have been cleaned up, and life went on but they were different parts to the GTK parts. You’re simply seeing the same process occur here.
I am not the only one, read our previous gnome article and read the comments there for more.
That isn’t good enough. I’ll assume you meant the “GNOME wishlist” story. I see a mix of comments on glade there, some saying it rules, some saying they prefer Qt Designer, ALL saying they are both much better than some of the alternatives most people have to use (primarily win32 based designers).
Rather than believe what anonymous people post to OSNews, why not write a GTK+ app yourself using libglade and python or GTKmm, I mean a serious app, then give us a review of what you found hard or didn’t like. Only when you have actually coded using the tools available can you comment on whether they are any good or not.
In my experience, both Qt Designer and VS.NET are/have better RAD tools than Glade. By using Glade, yes the little I used it, it put me off immediately.
Well, I do know what I am talking about regarding OO, I just am not familiar with this specific case, which is why I put a freaking disclaimer, dude, go buy some manners.
Anonymous above has mentioned that one of the problems is that programmers touched the old dialog in a lower level than desired, and so you can’t wrap the new API with a compatibility layer. That is also a problem that disappears when you use a proper OO language, because you can hide the non-public interface.
Anyway: Using a langauge that support OO makes that evolutionary process you mention faster, which is why Qt’s file selector API has not changed much, but only been extended. This GTK file selector thing has been an ongoing process for 4 years and 6 major releases!
Again, I don’t know if it’s because of data hiding, of encapsulation, or simply a wretched design, but all those things benefit from using a better language.
Also, KDE/Qt’s fs dialogs being similar to windows is not really relevant to the issue of evolutionary/breaking change. The dialogs have changed widely between releases, the APIs haven’t, and the changes have not caused apps to break completely.
Well, I do know what I am talking about regarding OO, I just am not familiar with this specific case, which is why I put a freaking disclaimer, dude, go buy some manners.
Dude, putting a “freaking disclaimer” on a random guess does not make it any less informed. It’s still a random, completely wrong, guess. Solution: don’t make random guesses about stuff with which you are not familiar.
That is also a problem that disappears when you use a proper OO language, because you can hide the non-public interface.
No, you can hide interfaces in practically any language, certainly you can hide non-public interfaces in flat C or OO C. The problem was that it didn’t. That is the problem. It has nothing to do with what language was used. It has everything to do with bad design by the people who originally built it (and the gtk file selector is very old now).
Anyway: Using a langauge that support OO makes that evolutionary process you mention faster, which is why Qt’s file selector API has not changed much, but only been extended.
No, again, you are totally wrong. Evolving APIs has been done for years, in every language. The fact that the API is changing a lot now, in a short space of time, is because manpower is limited and only now has the issue reached the top of the todo list. If anything, extending APIs is *harder* in C++ because adding new virtual methods breaks the ABI, in fact, there are about a million rules about what you can and cannot change if you want to keep ABI. Note that’s not a problem with OO, it’s just a problem with the way C++ implements it.
This GTK file selector thing has been an ongoing process for 4 years and 6 major releases!
No it hasn’t. People have been bitching about it for a long time. Only in the last few months has work actually started on a replacement (thoughts about a new design were circulated back in February, but that’s just good planning).
Again, I don’t know if it’s because of data hiding, of encapsulation, or simply a wretched design, but all those things benefit from using a better language.
I’d note that none of those things are C specific (and in fact GTK+ is an object oriented API and practices encapsulation, data hiding and so on).
bad uses of OO can lead to really mess. the same with procedural langage like C
the main problem with GTK was some bad decision in early day
the same with QT in others things
QT2 changed things from QT1 too.
Objective C+Cocoa is really beautiful langage and API but it has a cost , many complex features (delegation for example) or cpu costly features (introspection )
and the NeXTstep/openstep/cocoa API took years to evolve and mature.
one thing, we need to _stop_ mistake langage and API !
please, give real examples and good arguments to criticize C or OO langage.
Well, I will chime in here. I don’t care for Glade. It’s not bad, just not great. I used it for code generation for my tsclient app and it was a damn mess that I still haven’t gotten entirely cleaned up. Code generation is Glade is worthless – once you have generated the UI, you pretty much don’t have the chance to do it again unless you want to include the files it spits out unchanged, which is stupid. Everyone says that you shouldn’t use the code generation – then remove/disable it or fix it. And the hookups for libglade aren’t what I wanted at the time. I really didn’t want to not use it so I could learn the GTK api much faster and I did that. The callback interface in Glade also leaves much to be desired and sends everything as a gpointer instead of allowing proper typing. That is my opinion, like it or don’t. Some people will like glade/libglade, I don’t.
I much prefer the designer in VS.net. It is much easier to use and ther is no need for code generation as it is automatic. It puts a reserved method in the class for GUI creation and parses it for the gui designer. This allows me to keep my UI in code and to modify it when I want to in code or the designer. It works great.
I have no comment on QT designer – I haven’t tried it since the it’s early days and no longer install QT or KDE.
Mike: Why are you so hostile? I see constructive criticism has been made about Glade and how it might be improved using methods from others. No need for your hostilities. And who says anyone needs anything “radical” in a file picker? That’s just the kind of “pie in the sky” crap that has kept GTK in the stone age in that regard.
It is possible to do OO programming in C.
It is possible to do data hiding in C.
It is possible to write ugly code in C++.
It is possible to write ugly code in Python.
It is possible to design a crappy API in any language.
Now, having the obvious out of the way, let’s say other things that are also obvious, but apparently some prefer to ignore:
It is harder to do OO programming in C.
It is harder to do data hiding in C.
It is harder to write ugly code in C++ (not too much).
It is harder to write ugly code in Python.
It is harder to design a OO API than a regular API.
It is harder to design a crappy OO API than a crappy regular API.
It is harder to design a crappy OO API when you actually have had to learn OO programming first, because you are using a language that supports it.
It is easier to design a crappy OO API when your background is 99% C, not OO, programming.
When something is harder, people do it less.
When something is easyer, people do it more.
I won’t bother connecting the dots.
And Mike: of course it has been a concern for 4 years. Just because it has been a concern noone has bothered doing anything about doesn’t make it any less “concern”.
Now, grow up and get into the 80s, old C style programming is antiquated, and leads to hard-to-control APIs.
Did any of you notice that Xfree86 actually put out a release candidate for 4.4.0 on 04-Dec?
I searched the site but was unable to find any notes on what new to expect in the release.
Yes, the xfree86.org site is not very good maintained (e.g. old news not appearing in the news archive).
Woot, nicely said.
Owen Taylor mentions Render performance as a factor making GTK+ slow. Accelerated render is pretty fast on NVIDIA hardware, and GTK+, if anything, is slower with the NVIDIA binary drivers than with the regular nv drivers, which don’t accelerate Render. A lot of people think that a major bottleneck is Pango, which is extremely slow for laying out text.
Very nice.
I especially like the last statement “When something is harder, people do it less. When something is easyer [sic], people do it more.”.
My own variant is that when it’s easier to do the wrong thing than the right thing, people will be doing the wrong thing. A good API is one where it’s easier to the the right thing than the wrong thing.
Argh, ugly typo. I just copied the first line,
then edited, and I must have thought “easy”… Oh, well, I hope if someone ever picks it up, it will get corrected 😉
Can’t agree more.
I’d like to see more people evaluating the java gnome bindings, which are a pretty good option to do OO with gnome, and just need some more developers it seems. C# isnt the only kid in town, in fact, Java is its inspirator 😛
I would like to know if we can expect another “earthquake” (ala gnome 1.x – gnome 2.x transition), I mean, all apps being rewritten, a desktop with apps looking different from each other, two GTK versions in memory at the same time, etc, etc. For GTK3/gnome3 ? Is it unavoidable? Is it the cost of open source?
C vs. C++:
– C++ binary API is not stable (check GCC changelogs to see how often it changes)
It would be nice if Glade would support custom widgets.
Currently you have three options:
1) wait for Glade v3 which is supposed to have support for these (when!???)
2) Do a little extra code and have your widget as gray box in Glade
3) Code your widget into Glade and recompile Glade
I gotta agree with you there. I’m also of the opinion that Java is the cleaner, more elegant language (just my opinion). Unfortunately, it looks like the Java-GNOME bindings are pretty immature. This is where Java’s cross-platform nature actually hurts. Java has cross-platform GUI libraries, so it is difficult to drum up support for non-cross-platform libraries.
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
So if I switch it off will I see a small performance increase?
Roberto, your whole argument is based on the assumption that people don’t design APIs, they hack them out. That might have been true once upon a time for GTK, but certainly isn’t the case now, and in fact the new file selector API is object-oriented and seems to be pretty well designed.
Yes, the old file picker API was not very well designed. If it’d been written in C++, there’s no guarantee it’d be any better – it’s still possible to make members public when they should be private because that’s easier than writing solid interfaces, it’s still possible to not write pluggable code and so on.
In other words, this is like saying “That house would be much better layed out if only they’d used Black and Decker drills to build it” – obviously that statement is absurd, in a well built house you’d hope that the tools used would not affect the position of the living room relative to the kitchen.
And Mike: of course it has been a concern for 4 years. Just because it has been a concern noone has bothered doing anything about doesn’t make it any less “concern”.
This statement is meaningless – you originally asserted that “the filepicker has been a concern for 4 years” because GTK was written in C, which is clearly false. Of course it’s been a concern for four years, but that isn’t the case because of what language is used to write it in.
Now, grow up and get into the 80s, old C style programming is antiquated, and leads to hard-to-control APIs.
By “old C style” I guess you mean procedural, which certainly isn’t limited to C. But, that’s OK, because GTK is not “old C style” nor procedural, so I’m not sure how that this insult is relevant.
Rayiner: The nVidia drivers do not accelerate XRender by default of course, you must switch that on manually (which makes the drivers rather unstable).
I remember reading somewhere that in XFree 4.3 at least, the open source nv drivers are slightly faster at 2D graphics than the binary only ones. Not sure if that’s accurate or not, but they are certainly comparable, so you can’t really judge simply by swapping drivers like that.
Yes, Pango takes its toll cycle-wise, that’s the price you pay for proper unicode support (which I think we’d all agree is worth it), but quite a few profiles show GTK sitting on the X server waiting for it to render text – XFree reads from the framebuffer in order to do the blending, which is apparently quite slow.
Writing something C++ won’t automatically make it better. Bad OO code is just as bad (or worse) than bad procedural code.
I suggest you read “The Art of Unix Programming” by Eric Raymond. It may clear up some myths you hold about programming languages. C++ is not the silver bullet you think it is.
Mike, you just ignored his whole point.
and anything done in a structured language is NOT OO. you can fake OO, but it is not OO, Period.
if you READ what he said, he is saying what you just said, you CAN do bad stuff in C++, but C does not allow classes and objects which make code reuse and APIs nicer to write which in turn makes Widget sets easier to build. it canbe done in C, no one says it can’t, but it is harder to do it well than in an OO language.
There is something beautiful about the new (and the old) file chooser of Gtk: It’s the same for plain Gtk and GNOME. Not just that, it will even be able to use the GnomeVFS features when available even for plain Gtk apps. Plain Qt apps can only use a considerably crippled file chooser, compared to the KDE file chooser.
But just as much as this has nothing to do with the choice of language, the design flaws of the old dialog had nothing to do with the choice of language. As I understand it, the main problem was allowing applications to directly manipulate the dialog to solve the “custom widgets” issue, which obviously wasn’t very useful in the long run. I don’t see why you couldn’t have taken the same wrong approach with an OO language.
It may well be that using such a language is superior for avoiding mistakes, but it’s really provocative and inappropriate IMO to make every design flaw of an application into a language argument. Besides, if C++ would be such a holy grail, Qt would have to be lightyears ahead of Gtk, considering that
– it was started earlier
– it has a whole company of full payed developers behind it
– it is using the allegdly far superior language.
But as a matter of fact, Gtk is close behind Qt, even topping it at some areas and topping most other toolkits, even those written in OO languages. How could that be?
Personally, I think it’s much more important to note the wealth of wonderful languages we can choose to write Gtk based applications, instead of bickering about the language the toolkit was written in.
Some people seem to be saying that the KDE file dialog is based on windows. Actually, I designed the API and that was designed independently of the look and feel. The look and feel at the point I originally wrote this code was based on that of Motif (with the major errors fixed). The API was designed based on the existing Qt dialog. In the 1.x release I made a few fuck ups in the API which were sorted out in 2.0, none of these required any application changes I am aware of.
Rich.
I don’t see why you couldn’t have taken the same wrong approach with an OO language.
That exact same wrong approach was taken by BeOS in C++.
I think I see the conceptual mistake you’re making – I made it myself once, too.
You believe you cannot do object oriented programming in a language that does not have native support for it.
This belief seems intuitively correct. How do you have a class, how do you derive from it, without the “class” and “inherited” keywords (words taken from object pascal)?
Well, then you have an epiphany and realise that object oriented coding is about a design methodology, not what your code looks like. If you can inherit from a piece of code, if that code is a modular component that presents a public interface, if it uses properties or getters/setters rather than direct access (when appropriate), if designed to support reuse through virtual methods and signals etc then the code is object-oriented.
Those were just examples, of course there is more to OO than that, but the point is that while doing object orientation in a language that does not support it is tedious and often involves a lot of work, it’s certainly possible.
Is the fact that GTK is written in C ideal? No, but when it was started C++ was not really an obvious choice either. If starting GTK afresh today maybe C++ would be used as support for it on free platforms is much better.
However, does being written in C make it less object oriented, harder to reuse, does it mean there is no inheritance and no properties? Of course not. GObject has all these things.
So to say that “C does not allow classes” is wrong – you can do classes in assembler if you so wish, it’d just be rather painful. Classes and OOP is about design, not what the lines of code look like.
code generation in glade isnt that bad. some people really do it injustice. instead of praising it for its avant-garde of being able to render ui’s from xml files (hello libglade – thats the way it _should_ be used), people blame glade when they generate code with it they think they cant change afterwards. either when you use glade:
DON’T edit the interfaces.c et others files by hand
just include them. make function calls from within glade.
when the gui is done, hook it into your main program. naturally in main.c. thats it.
and glade as well as other “RAD” tools are only good for quick ui mockups, or little programs. if you seriously want to code something, be it a website or a program ui in a WYSIWYG editor the result is what you deserve (TRIWYD)
Yes, sorry Richard, I was pretty imprecise there. I was talking about the look and feel being similar these days then went off on a tangent and started talking about the stability of the API but didn’t actually make it obvious I was talking about something different. I’ve never seen the KDE filepicker API – I can only assume it’s a lot better than the old GTK one was!
(more rubbish)
if the fileselector in gtk changes – see the ximian patches, you dont have to patch all programms just libgtk or whatever it is called. gnome, as well as c is not retarded.
i am sick of the C++ vs. C trolls. the languages are both totally different stories. sure OO is nice when you write your foo.function objects, but its not a solution to bad programming. when you are a bad programmer it doesnt matter if you use C or C++, python or mono, cause if you absuse a language, no language design can safe you. thats true for C as well as C++. and i see neither of these faults in Qt or GTK. and freedesktop is a good move in the right direction. if you look at windows it doesnt consist of one toolkit either, it just happens they all look and behave the same, as well as share the same resource information.
if you guys have nothing to do than to go to the holy kde vs. gnome war. go on. waste your time but mine for now is wasted enough.
Mike, it helps if you read before you reply 😉
I agree that it is possible to write OO code in C. I just say it’s:
a) Harder
b) Uglier
c) More error prone
than doing it in a language that supports OOP.
Also, I even said myself that it is possible to design a OO API using C. I jsut said that the API will usually be:
a) Harder
b) Uglier
c) More error prone
than an API designed by an equally competent guy using a language that supports OOP.
smoke: the thing is… the change in the latest GTK+ file selector API *is* making people change the apps, so what are you talking about?
Russell: I qwork really hard to ignore everything ESR says, does, or writes. He is a barely competent programmer (and I am being nice here). Have you actually *read* any of his code? BTW: he is a python advocate, too 😉
It would be nice to see some cold hard facts comparing rendering performance between native X 2D against OpenGL 2D ops.
It could be that:
(1) The slow draw()s we are so accustomed of seeing can be traced to a poor 2D implementation in XFree.
(2) Hardware-assisted 2D draw()s happen only OpenGL.
Forgot to say this: And I am not a very big fan of C++, either. Hell, I’d rank C++ as one of the worst 5 languages I know, above C, TCL, JORF and Perl.
> I’ve never seen the KDE filepicker API – I can only
> assume it’s a lot better than the old GTK one was!
Naturally – I designed it! 😉
Seriously though, what I did in designing the API was to make the commonly used access points very simple. Most apps do not need a powerfull API, they need a simple robust one.
The underlying implementation was a generalisation of the Qt file API that provided a collection of high-level classes for accessing the KDE network aware IO system. This implementation was developed independently of the GUI in the main part (most of the GUI was operational within 24 hours of me starting it and was written at the first KDE conference during an all-night hacking session). The GUI I put together combined ideas from a few prototypes that were floating around at the time into a single coherent structure, and added some concepts of my own. Overall, I think this effort has been shown to be fairly successful.
Rich.
nothing wrong with python :-), but yes ESR is a writer not a coder.
Even with Render acceleration enabled, GTK+ is slow. The reason they’re “experimental” is not so much that they make the drivers unstable (I’ve not noticed any stability problems and I use them all the time) but because they apparently only accelerate enough of Render to speed up text compositing.
Also, someone did say that the ‘nv’ drivers were faster at 2D than the ‘nvidia’ drivers, but that’s not true. I posted x11perf numbers on the SciTech SNAP thread. The result was that the ‘nv’ driver is only really accelerated for blits and fills (its many times slower for other operations) and even then is about 20% slower than the NVIDIA binary drivers.
Hmm, maybe I should try enabling render accel on my drivers again then – last time I tried (a few builds ago I guess) i got wierd rendering artifacts and stuff. No actual crashes though.
It is quite sad they’re not focusing on getting a better performance…
Victor.
Check out GNUStep’s “Renaissance” …
It’s quite flexible.
http://www.gnustep.it/Renaissance/
OOP is not enough. OOP is only part of a friendlier architecture. OOP doesn’t mean very much by itself.
It has nothing to do with the language. It has everything to do with the design, craftmanship and implementation. And on the side of the programmer, it has everything to do with the attitude. I don’t believe OO in C is any stranger than OO in C++/Python/Java/etc. And frankly, I don’t care.
GTK+ and Glade are tools, and good ones at that. You can learn how to use them and contribute to making them better, or you can just whine about them. I can swear half of the people who bitch about either of them have never even used them.
You know a person has used a tool when they can give a balanced objective view of it. I mean someone who mentions both the strengths and weakness of a tool and demonstrates what situations to leverage or exploit either.
Like I always say, if GTK sucks so much, how does it produce such high quality and high caliber environments and applications like, The Gimp, Evolution, Gaim, Epiphany, to mention a few. If it sucked so much or if C was a pain to do OO in, why do these and many more tools exist?
GTK+ is the track to stay on if you are interested in the open source side of Linux. The technology does have a future, and a new system can and will be designed to replace GTK+, but it’s too early to lead that effort, and there are many factors to consider, we actually need a knowledge base, and with that, it is possible to do a better job than what the industry has realized thus far.
Which are the main new features users and developers will enjoy with the release of GTK+ 2.4?
Well … some things KDE/Qt has had since ages.
Seriously:
File selector – does that really need a comment?
Dropdown widget – KComboBox.
Completion – KCompletion.
A new menu and toolbar action-based API – KAction.
Editable toolbars – done with KXMLGUI
All of them available since KDE2.0, as can be verified using webcvs.kde.org.
The short answer is that KDE has been around longer than GNOME. GNOME is actually trying to get as much of that functionality into the toolkit, rather than in the desktop. This benefits all the apps that use the toolkit. Example, the GIMP will be able to use the new fileselector, the combobox, the complettion, the editable toolbars. With KDE a lot os apps cannot use those features if they want to be KDE independent.
The reason apps like GAIM can be able to feel like part of GNOME even though they ae not, is because a lot of the functionality is in the toolkit too. The advantage is that the same community developing GTK develops GNOME, so they can reduce the duplication.
Check in KDe how Qt only apps can feel out of place on the desktop. Of the top of my head, OPera, yammmi, texmaker, etc. The advantage of the GNOME way, IMO, is that it is easier to include apps in GNOME even if they are not developed directly with GNOME in mind, like Abiword. Its cross platform, but it looks right at home on the GNOME desktop.
And the even shorter answer is:
Who the hell cares?!
It doesn’t matter who’s the first to implement something. What matters is that GTK 2.4 has it NOW. The “we-did-it-before-you-so-we-are-better-than-you” crap are only used by arrogant and elitist trolls who want to raise their self-esteem by flaming others’ work.
One of the important design criteria for GTK+ is language binding friendlyness. Owen actually once said something like “The number one tip for gtk+ programmers is, use another language than C”.
It’s not a coincidence that gtk+ has lots of nice language bindings; we are always making sure that new API is easily wrapped. Using C instead of C++ is one decision to that end. Using a C based object system with introspection is another.
A C API is more easily wrapped, because it doesn’t have the same ABI/name mangling issues, and because there is a lot fewer features that the wrappers have to deal with. You can export a C API from a C++ library, but then you wouldn’t have gained much, because then you couldn’t actually use any C++ features in the API.
On the other hand wrapping an object-oriented C API with a high quality C++ one is possible as the gtkmm bindings prove.
“It is possible to do data hiding in C. ”
Not really. You still can access the “hidden” data with some pointer arithmetic.
Ignore the last comment. 😉
With the size of GNOME or KDE’s API, a hand-made wrapper for any language is a lost cause.
And automatic or semi-automatic wrapper generators for C++ are just as good as for C.
For example, PyKDE is done by a single guy, and it’s usually available a week or so after release.
Just add to your X86Config file:
Option “RenderAccel” “true”
and if you have xfree86 4.3 also add:
Option “CIOverlay” “true”
And of course you need to have AGPGART compiled with your kernel.
“It is possible to do data hiding in C. ”
Not really. You still can access the “hidden” data with some pointer arithmetic.
And in Java, C# you can access private members using reflection. Visibility is more for documenting how a class should be used than forcing it to be used a certain way.
now!!! finally some one makes an argument for writing it in C that I can agree with!!!
OK, you have swayed me, but I still think more programs should use the language bindings rather than the standard API.
AHHHHHHHH you are killing me!!!!!
Visibility IS for forcing a certain way of using a class!!! that is the entire point!!!!!
all I need to do is keep the interface the same and I can change the names of the functions in the private section to what ever the hell I want as long as the public functions are modified for the new names. I can change the algorithms, I can do what ever I want and the user of the class need not know it.
and if you enable renderaccel your nvidia driver will hardlock xfree a couple of times per day. great hint!
> You still can access the “hidden” data with some pointer arithmetic.
Same as in C++
I’ve had renderaccel enabled for months, and I can’t remember locking X in that time. On the other hand I do remember and still enjoy the performance benefits, which i must say, are very impressive.
C++, Java, and C# all allow the mischevious programmer to access the data by going behind the scenes and doing non-good but still possible things. They are not magical. The ability is still there, just like pointer arithmetic in C.
Your intelligence and maturity here is astounding.
Visibility IS for forcing a certain way of using a class!!! that is the entire point!!!!!
Then why did the designers of Java and C# decide to allow access to private members through reflection? Visibility information is part of the class metadata, they could have restricted it if they wanted to.
If you create a method and write “don’t pass in null” in your javadoc comment, that’s part of the method specification. A user of your class can still pass null to that method but their code isn’t guaranteed to work. Same thing with visibility, someone can call your private method if they want to but their code isn’t guaranteed to always work.
I want to attempt to consolidate the points about OOP in C vs C++ or any other OO Language.
The first point is OOP is a paradigm — not a language. You can do OOP in any language that supports structured data types, pointers, and function and data hiding. C supports all of this.
The second point is that OOP in C does not have to be ugly. I have personal experience in writing OOP in C and it looks very elegant. Not only that, in my OOP C library, even classes are objects. Here is a sample of code:
http://home.rochester.rr.com/bigbyofrocny/desktop/bbigby/OOC-Exampl…
As you have probably guessed, my OOP library supports exception-handling and design-by-contract. See http://www.eiffel.com for more info on DBC. See http://home.rochester.rr.com/GEF/GEF.html for information about my exception-handling/design-by-contract library for C programmers. GEF stands for General Exception-Handling Facility.
Another point is that my OOP C library supports the following:
(1) Single inheritance
(2) Polymorphism – All messages are virtual.
(3) All Classes and Metaclasses are objects (ala Smalltalk)
(4) Memory is an object.
(5) Exception-handling
(6) Design by Contract – Preconditions, Postconditions, Invariants. Always use assertion checking for programmer errors. Use exception-handling for all other types of errors. Most errors are programmer errors.
C is not necessarily harder to do OOP in. The difficulty is creating the initial support. After that, it’s easy. I have created some support utilities that will scan my C files for any C function that has the tag, “ctMethod”, and generates the virtual tables for the class. I also have a tool that will automatically create a header file that contains the includes for all of the message functions that a .c file invokes. In the example, above, the function, ctNotEmpty(), is a message boolean predicate function that sends the message “Not Empty” to the object, “receiver”. This variable represents the the “object” form of the variable, “self”. “self” is the real representation of the instance. To send a message to an object, you must change the form (cast, if you will) it to a ctObject_t. That’s the only legal cast in the system and it is the only one that makes sense. All instances can be legally viewed as ctObjects_t. Like I said, ultimately, everything is an object.
Anyway, I hope that I made my point. I’d like to say more but I have to run. I have to go out this morning for brunch. If you’d like to receive a response directly, e-mail me directly.
The URL for the GEF package should have been the following:
http://home.rochester.rr.com/bigbyofrocny/GEF
Sorry.
Owen referred to the freedesktop X server extensions allowing for completely smooth window resizing. This would be really cool, however I have not been able to find anything on it via google. Which extension, used how, would provide smooth resizing? The best I could find was a thread where somebody said he wanted to use it that way, and he was told that he misunderstood the extension.