Linked by Eugenia Loli on Fri 19th Dec 2003 02:24 UTC
Original OSNews Interviews 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!
Order by: Score:
Nice - but over my head
by Alastair Stevens on Thu 18th Dec 2003 17:04 UTC

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 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!

Excellent!
by Erwos on Thu 18th Dec 2003 17:06 UTC

Great interview. Covers all the major issues, and provides insight into the direction GTK+ is heading.

-Erwos

Backward compatiable or not?
by gtk-user on Thu 18th Dec 2003 17:29 UTC

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.

RE: Backward compatiable or not?
by Eugenia on Thu 18th Dec 2003 17:31 UTC

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.

What I want to know
by blah on Thu 18th Dec 2003 17:39 UTC

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.

API stable 2.x series, at least
by Anonymous on Thu 18th Dec 2003 17:39 UTC

From the GTK+ FAQ:

"A 3.0 release would be the earliest point at which we would make a source and binary incompatible release."

On Glade
by Mike Hearn on Thu 18th Dec 2003 17:51 UTC

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).

RE: On Glade
by Eugenia on Thu 18th Dec 2003 17:52 UTC

Whatever I had to say on Glade, I already said it to its developer last week in an email exchange we had.

Re: What I want to know
by Erwos on Thu 18th Dec 2003 17:53 UTC

"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

performance issue?
by i_code_too_much on Thu 18th Dec 2003 18:00 UTC

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.

re: Re: What I want to know
by blah on Thu 18th Dec 2003 18:03 UTC

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.

v this little P$$$$$
by Anonymous on Thu 18th Dec 2003 18:03 UTC
Commercial Support
by Anonymous on Thu 18th Dec 2003 18:12 UTC

What this toolkit is missing is commercial support. Whom can you pay to get support if you need it?

RE: Commercial Support
by Eugenia on Thu 18th Dec 2003 18:13 UTC

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

What's OO
by scrooch on Thu 18th Dec 2003 18:14 UTC

Blah, what's OO?

RE: performance issue?
by Roy on Thu 18th Dec 2003 18:16 UTC

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.

New Fileselector
by Anonymous on Thu 18th Dec 2003 18:17 UTC

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)?

Re: New Fileselector
by Anonymous on Thu 18th Dec 2003 18:29 UTC

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.

Re: New fileselector
by Roberto on Thu 18th Dec 2003 18:30 UTC

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.

Glade
by Anonymous on Thu 18th Dec 2003 18:31 UTC

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.

RE: Glade
by Eugenia on Thu 18th Dec 2003 18:32 UTC

I am not the only one, read our previous gnome article and read the comments there for more.

RE : What's OO
by nego` on Thu 18th Dec 2003 18:39 UTC

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.

RE : What's OO
by KOPY on Thu 18th Dec 2003 18:49 UTC

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#, ...

Re: Roberto
by Mike Hearn on Thu 18th Dec 2003 18:52 UTC

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.

RE: Glade
by Mike Hearn on Thu 18th Dec 2003 19:01 UTC

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.

RE: performance issue?
by Eugenia on Thu 18th Dec 2003 19:06 UTC

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.

Re: Mike Hearn
by Roberto on Thu 18th Dec 2003 19:07 UTC

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.

Re: Roberto
by Mike Hearn on Thu 18th Dec 2003 19:23 UTC

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).

OO language are not magic
by michel on Thu 18th Dec 2003 19:25 UTC

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.

RE: Glade
by Erick on Thu 18th Dec 2003 19:29 UTC

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.

Stating the obvious
by Roberto on Thu 18th Dec 2003 19:36 UTC

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.

Xfree86
by Ajay on Thu 18th Dec 2003 19:38 UTC

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.

Re: Xfree86
by Anonymous on Thu 18th Dec 2003 19:47 UTC

Yes, the xfree86.org site is not very good maintained (e.g. old news not appearing in the news archive).

Props to Roberto
by blah on Thu 18th Dec 2003 19:52 UTC

Woot, nicely said.

Render performance?
by Rayiner Hashem on Thu 18th Dec 2003 20:06 UTC

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.

Re; Roberto
by JBQ on Thu 18th Dec 2003 20:06 UTC

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.

Re: JBQ
by Roberto on Thu 18th Dec 2003 20:11 UTC

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 ;-)

re:Stating the obvious
by danlu on Thu 18th Dec 2003 20:16 UTC

Can't agree more.

C# vs Java
by datadevil on Thu 18th Dec 2003 20:40 UTC

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 :-P

About futuro sourse code incompatiblity
by insdr on Thu 18th Dec 2003 20:57 UTC

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?

Glade wish and note on C vs. C++
by Anonymous on Thu 18th Dec 2003 21:01 UTC

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

RE: C# vs Java
by Roy on Thu 18th Dec 2003 21:05 UTC

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.

anti-aliased text give performance drop?
by John Blink on Thu 18th Dec 2003 22:16 UTC

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?

Stuff
by Mike Hearn on Thu 18th Dec 2003 22:19 UTC

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.

Re: Render performance?
by Mike Hearn on Thu 18th Dec 2003 22:23 UTC

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.

v Re; Roberto
by John Blink on Thu 18th Dec 2003 22:33 UTC
Re: Roberto
by Russell Jackson on Thu 18th Dec 2003 22:57 UTC

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.

re: Stuff
by blah on Thu 18th Dec 2003 23:12 UTC

Mike, you just ignored his whole point.

re:stuff
by blah on Thu 18th Dec 2003 23:13 UTC

and anything done in a structured language is NOT OO. you can fake OO, but it is not OO, Period.

re: Re: Roberto
by blah on Thu 18th Dec 2003 23:17 UTC

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.

Side note about file choosers and languages
by Spark on Thu 18th Dec 2003 23:18 UTC

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.

Lots of rubbish
by Richard Moore on Thu 18th Dec 2003 23:21 UTC

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.

Re: Side note about file choosers and languages
by JBQ on Thu 18th Dec 2003 23:22 UTC

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++.

Re: blah
by Mike Hearn on Thu 18th Dec 2003 23:25 UTC

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.

RE: Glade
by smoke on Thu 18th Dec 2003 23:29 UTC

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)

Re: Lots of rubbish
by Mike Hearn on Thu 18th Dec 2003 23:35 UTC

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!

RE: Lots of rubbish
by smoke on Thu 18th Dec 2003 23:40 UTC

(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.

Re: Mike Hearn & others
by Roberto on Thu 18th Dec 2003 23:55 UTC

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 ;-)

X vs OpenGL 2D ops
by nymia on Thu 18th Dec 2003 23:58 UTC

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.

Re: Russell Jackson
by Roberto on Thu 18th Dec 2003 23:59 UTC

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.

Re: Lots of rubbish
by Richard Moore on Fri 19th Dec 2003 00:00 UTC

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


re: roberto
by blah on Fri 19th Dec 2003 00:01 UTC

nothing wrong with python :-), but yes ESR is a writer not a coder.

@Mike Hearn
by Rayiner Hashem on Fri 19th Dec 2003 00:12 UTC

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.

@Rayiner
by Mike Hearn on Fri 19th Dec 2003 00:14 UTC

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.

Performance issues...
by Victor on Fri 19th Dec 2003 02:04 UTC

It is quite sad they're not focusing on getting a better performance...

Victor.

XML GUI description
by Anonymous on Fri 19th Dec 2003 02:47 UTC

Check out GNUStep's "Renaissance" ...

It's quite flexible.

http://www.gnustep.it/Renaissance/

...
by Anonymous on Fri 19th Dec 2003 03:36 UTC

OOP is not enough. OOP is only part of a friendlier architecture. OOP doesn't mean very much by itself.

The are tools not religious practices.
by Anonymous on Fri 19th Dec 2003 04:15 UTC

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?

...
by Anonymous on Fri 19th Dec 2003 05:51 UTC

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.

Shorter answer to question #1
by Zelvaj on Fri 19th Dec 2003 10:08 UTC

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.

RE: Zelvaj
by Maynard on Fri 19th Dec 2003 11:28 UTC

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.

Re: Zelvaj
by Anonymous on Fri 19th Dec 2003 11:44 UTC

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.

Languages
by Søren Sandmann on Fri 19th Dec 2003 12:19 UTC

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.

RE: Stating the obvious
by Anonymous on Fri 19th Dec 2003 13:25 UTC

"It is possible to do data hiding in C. "

Not really. You still can access the "hidden" data with some pointer arithmetic.

RE: Stating the obvious
by Anonymous on Fri 19th Dec 2003 13:27 UTC

Ignore the last comment. ;-)

Re: Soren
by Roberto on Fri 19th Dec 2003 13:39 UTC

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.

Re: Render performance?
by Sagres on Fri 19th Dec 2003 15:18 UTC

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.



RE: Stating the obvious
by ethzero on Fri 19th Dec 2003 15:28 UTC

"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.

 re:Languages
by blah on Fri 19th Dec 2003 16:02 UTC

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.

 Re:RE: Stating the obvious
by blah on Fri 19th Dec 2003 16:06 UTC

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.

Re: Render performance?
by smoke on Fri 19th Dec 2003 16:52 UTC

and if you enable renderaccel your nvidia driver will hardlock xfree a couple of times per day. great hint!

RE: Stating the obvious
by Vitaly on Fri 19th Dec 2003 17:10 UTC

> You still can access the "hidden" data with some pointer arithmetic.
Same as in C++

Re: smoke
by mxcl on Fri 19th Dec 2003 18:01 UTC

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.

Re:RE: Stating the obvious
by Tristan McCann on Fri 19th Dec 2003 19:39 UTC

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.

Re:RE: Stating the obvious
by ethzero on Fri 19th Dec 2003 21:46 UTC

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.

v Re: Stating the obvious
by Anonymous on Fri 19th Dec 2003 23:26 UTC
RE:Re:RE: Stating the obvious
by Bruce on Sun 21st Dec 2003 15:31 UTC

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.

RE:Re:RE: Stating the obvious
by Bruce on Sun 21st Dec 2003 22:05 UTC

The URL for the GEF package should have been the following:

http://home.rochester.rr.com/bigbyofrocny/GEF

Sorry.

Smooth resizing - where?
by Matthew Toseland on Tue 23rd Dec 2003 02:29 UTC

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.