OSNews

kdevelop is awesome but if Anjuta integrates Glade-3 then it can well become even more successful than kdevelop.

I see very little gtk horn tooting. Please, don't insult us for what we don't really do. I ALWAYS see some kid who's written hello world write something stupid about the superiority of QT.

Anyway, this change should be fine since I believe libglade is being put into gtk3. It'll be much nicer to have xml interface files rather than globs of c code; even if there's a small speed cost.

What'd be really nice though would be a compile time translation from the xml to the c code; then compile the c.

..very good...
...and very buggy!

;)

Anjuta2 will integrate itself very good with Glade-3. Now that is a killer argument against KDevelop+Designer

Wouldn't that rather be a killer argument for Anjuta2+Glade-3 instead of an argument against KDevelop+Designer?

By the way, in my version of KDevelop (3.something), the designer seems to integrated...

Well, everyone should use what he likes to.

I wholeheartedly agree ;-)

The problem is: Qt vs. GTK+. To be honest, I love C language, pure C is one of the simplest, the most logical and efficient languages ever invented (yes, I mean this). But GTK+ is a mess. Why implement object oriented programming in C? Why implement things such as GObject in C?

You answered your own question, C is simple, logical and efficient. And it's easier to create bindings to other languages than with C++.

And yes, you can always use Python, C++ or Java to write GTL+ apps, but they will use basic library written in C. That's unefficient, illogical and stupid.

Why is it unefficient [sic], illogical and stupid? They are thin wrappers around the C library and provide almost no performance penalty. Do you think that using Python with Qt is also unefficient [sic], illogical and stupid?

"Oh, and BTW: have a look here: http://developer.kde.org/language-bindings/
"

Except that the information on that page is out of date. The C# binding never really made it off the ground and apparently is abandoned.

May I add that only the Ruby, Python and (I think) Java bindings are properly alive. The same can be said for C++ (twice), Java, C#, Python, Ruby, Perl, Ada, Haskell, Ocaml, Pascal, and PHP for GTK+. True, there are other QT bindings, but hell, there are lots more GTK+ bindings out there that are semi alive.

GTK+ is multi(programming)lingual in such a way that QT just CAN'T ever pull even. And don't come with "QT's C++ is so much beter then stock C++", we use Python, Haskell, Ada or whatever becouse we LIKE to programm in those languages. Not out of eficiancy or some other crap that means something like 2-10% speed increase in parts of the programm that are idle 99% of the time.

Except that the information on that page is out of date. The C# binding never really made it off the ground and apparently is abandoned.

Mono makes it possible to program in a number of interesting languages besides c#. Boo http://boo.codehaus.org, for your pythonesque scripting language built just for .NET, and Nemerle for your functional programming needs built just for .NET

You should define "almost no performance penalty." I'd bet that your typical glue layer between a python code and the c library costs around 3 function stacks. I don't know much about python/c integration, so maybe it's only 1 but I'd guess there's some extra overhead incurred by python plus overhead incurred by the glue code?

That's inexpensive in 99% of the cases. Occasionally you start talking about tiny efficiency losses (maybe during a series of pulse calls on a progress bar).

I'd agree that it's worth the tiny cost. But people are going to give you crap about your definition of inefficient.


But he is wrong. It's very smart to write wrappers for a lot of libraries in different languages. I think the cost of writing code in python will be higher than the cost of calling something in a wrapped library (that's what I'd mark as efficient verse inefficient, if the wrapper is faster than the code would be in the native language).

I don't know much about python/c integration, so maybe it's only 1 but I'd guess there's some extra overhead incurred by python plus overhead incurred by the glue code?

Considering how many of the standard Python libraries are just wrappers over C libraries as it is do you really think that Gtk is going to be a problem? The same is true for most of the other scripting languages. The only language I can think of offhand that will have a real performance penalty is Java and that's because of how inefficient JNI is.

c has nothing to do with gtk+ being slow. Gtk is slow for several other reasons:
1.) It renders widgets as SVG's on the fly (2.8)
2.) It dynamically allocates widgets physical space (I believe QT does this too)
3.) Pango is slow (this is what I've read)
4.) It's very very very structured. You'll find that if you read through the GTK API docs, it's a parent-child class structure of widgets which all bases off glibc's types. It's a PERFECT example of how c++ is a superset of c (technically it's not, but logically it is).

4.) It's very very very structured. You'll find that if you read through the GTK API docs, it's a parent-child class structure of widgets which all bases off glibc's types. It's a PERFECT example of how c++ is a superset of c (technically it's not, but logically it is).

Yes, that's what is all about. C is no good when you write so structured code with multi level inheritance etc. It is a big mess. The reason why C++ was created was not to write such code in C

Yes, that's what is all about. C is no good when you write so structured code with multi level inheritance etc. It is a big mess. The reason why C++ was created was not to write such code in C

Except C++ is a mess of its own. The majority of applications shouldn't be written in C or C++ anymore. Libraries are a different thing, but then C++ as the lowest common denominator has its problems with ABI and interfacing with other languages as easily as with C.

>Except C++ is a mess of its own. The majority of applications shouldn't be written in C or C++ anymore. Libraries are a different thing,...

i agree. C++ is really a mess. I look up to everyone who rally control this monster.
But for everyone who have used for some time java, c# or ruby, python it will be really hard to go back to C++ or even C.

Qt has the advantage that it makes C++ more easy on many points, but in the end it's still C++.
Just a simple example. Write a hello-world-gui-app with Gtkmm or Qt and with Gtk# or GNOME-Java.
If you use one of the C++ options you have 3 files (helloworldwindow.h, helloworldwindow.cpp, main.cpp). You will have to declare a class, inherit form your Designer/Glade window, implement the class in a .cpp file and write a main.cpp file to start Gtkmm/Qt and create an instance of the window.
The same think in a java or c# solution is just one file with 10-20 lines of code.

So often i heard the sentence "programmers are lacy". And i think it's right. After one year of using Java, C# and sometimes Python it's really painfull if i have to do someting in C++ or C.

I think it's time to concentrate on more highlevel language in the areas were it is usefull. GNOME/Gtk+ have this option through their great language bindings. Just the GNOME app Hackers should use them on a more regular basis.
On the Qt/KDE side it's more difficult, but i think the "Qt-C++" is quite good for some more years and Trolltech has already stated that they think about an official highlevel-language support beside C++.

> Write a hello-world-gui-app
[snip]
> If you use one of the C++ options you have 3 files
[snip]

Nonsense. The examples are often like that so you have a useful real-world example that you can build on. You can do a hello world in any language with very little code, but it would just be a hello world.

Murray.

>You can do a hello world in any language with very little code, but it would just be a hello world.

Yes, but who needs "just a hello world"-program?
If i compare for example the complexity of a C++ and java program than i have to use the language like i will use it in a useful real-world program.
And than you have exact the differences i have described:
C++: 2 files for each class, first declare everything and second implement everything and 1 main.cpp, include everything on the right place and so on.
Java or c#: one file of ~10lines of code.

The problem is: Qt vs. GTK+. To be honest, I love C language, pure C is one of the simplest, the most logical and efficient languages ever invented (yes, I mean this). But GTK+ is a mess. Why implement object oriented programming in C? Why implement things such as GObject in C?

I agree with you completely. Qt is superior in so many ways...but:

Some people (traditional Unix guys) don't like C++

and

The Qt license will always be a bit of a problem for some groups, like Novell, RedHat, Sun. Why did Novell buy Ximian?

Why did Novell buy Ximian?

Mono

Dear god, not the 'object orientation is the cure to everything! it slices, dices and cures the common cold! can I hear a praise the lord?!" rants by so-called programmers.

Object orientation is not the panacea to cure all programming ills - companies like SUN, IBM, Microsoft and to a lesser extent, Apple, may market it as such, in a hope you purchase their bloated programming tools, consultancy services and their tonnes of books that can fill the hermitage library - but the fact remains, object orientation is but one paradigm - it isn't the cure all.

As for the speed issues; the issues that surrounds GTK is Pango; and like I said before; the programmers want a FULL solution - not cheap, hacks that only benefit one language, they want a solution that fixes the fundamental problem once and for all, so that it doesn't need to be revisted in 3 months time - coupling the fix with the OpenGL + GLITZ backend to Cairo, plus the continued integration of GTK and Cairo, end users should start seeing a marked improvement in the performance of the GUI, not only in responsiveness but the quality of the text rendering as well.

The oo-discussion is kinda pointless here anyway, since the GObject design that gtk is using is object-oriented too. You don't need to have C++ to write object oriented code (it just makes it easier sometimes).

> The oo-discussion is kinda pointless here anyway,
> since the GObject design that gtk is using is
> object-oriented too.

Correction: it tries to _mimic_ object oriented design. But it's like with any CARGO CULT ( http://en.wikipedia.org/wiki/Cargo_cult ) "technology": If you try to mimic higher technology using inferior tools then you might end up with something that _looks_ close to the real deal. Still those solutions fall short to deliver all of the advantages of the real thing.

That's the reason why many of the core gtk people have learned their lesson and put their focus on C++, .NET or Java these days.

>That's the reason why many of the core gtk people have learned their lesson and put their focus on C++, .NET or Java these days.


Yup, youve got that right. And the reason they still program in C is to be able to use those libs from all those real OO languages and others too.

Except that the cargo cult similitude doesn't really hold, does it? The whole point of Feynman's cargo cult idea is that you _can't_ build a working headset by carving half coconuts, no matter how good a craftsman you are. You might be able to carve something resembling it on the surface, but the substance of the thing is totally different.
On the other hand, programming languages are deep-down all equivalent in the Turing sense. If you want to code with the OO paradigm, it will usually be quicker and simpler with languages that are already shaped for the task, but that doesnt really mean that they are a 'superior' technology as opposed to 'inferior' ones. In the end, everything boils down to machine code, and that's the lowest level code there's. Even lower than C. Would you call it an 'inferior' technology, or argue that you can't design OO patterns and end up with machine code? OO is a way to think and design. Languages come up and help you in that, or let you do it all with your own hands, but eventually it's a way of thinking, not something intrinsically embedded in the syntax of the language you chose.

Ah yes, you've made it clear. The difference there is that you have bias against GNOME preventing you from using logic?

http://developer.kde.org/documentation/library/3.5-api.php
and
http://developer.gnome.org/doc/API/
are comparable.

http://doc.kde.org doesn't exist.
http://doc.trolltech.com is comparable to http://gtk.org/api/

There are 3 articles about bonobo, hardly making the docs "full" of info about it. It is good practice to keep documentation of legacy around.

they are both cross platform. qt is made by a company called trolltech, and is under a dual liscence (gpl on linux, non-gpl per developer liscence on everything else). skype is one of the bigger(cross platform) apps i know that uses it.

gtk is the toolkit used by gnome, and is gpl on every platform its ported to (including windows/mac). again, it is quite full featured, and has very well maintained bindings to pretty much all the popular languages. the official gui designer (glade) is language agnostic, it will generate an xml file that you call from your app, which uses it, libglade, and the gtk bindings to build the gui. gtk on windows isnt as good as on windows, but its functional, and free in every sense of the word.

imho, qt is better on non linux platforms, but you pay for it. gtk on non linux platforms is more an afterthought, but noone is trying to make a living off it so i guess its understandable.

im sorry, i was mistaken, thanks for the correction.

there is a difference between a mistake, and fud. read my post, i was in no way attempting to slander qt. i dont use kde or qt, dont have qt installed on my system, and havnt touched a qt app in over a year. i knew the liscencing previous to that, and had no reason to think there had been a change.

> i dont use kde or qt, dont have qt installed on my
> system, and havnt touched a qt app in over a year.
> i knew the liscencing previous to that, and had no
> reason to think there had been a change.

I believe you when you say you didn't spread wrong information on purpose. But your info is older than two years. You said it was "non-gpl per developer licence on everything else". But Qt3 became available for the Mac under the GPL in 2003: http://www.trolltech.com/newsroom/announcements/00000131.html

As "Anonymous (IP: 132.177.78.---)" said, Qt4 for Windows is now also available under the GPL.

Same thing here on opensuse 10. There aren't even any buttons on the floating toolbar.