This version of Glade (Glade-3) is a complete rewrite of the original Glade codebase. One of the main differences from glade-2 is that C code generation has been removed from glade-3; the preferred way to use glade files is with libglade. Another main difference is that glade-3 was designed to make maximal use of GObject introspection, thus easing the integration of external toolkits and handling widgets, signals and properties genericly. It has a few useful new features such as stacked Undo/Redo and Multiple Project support and respects the same XML format as glade-2.

I am not a programmer, so I have not dea of their merit, but this is a development release, so noone actually knows.

All linux artiles will have a ubuntu user tooting his horn (unless its a ubuntu article, where the rest will be getting their own back...), with qt, gtk zealots will toot their horns. with gtk, the qt zealots will crawl out. I find this tiring.

All the while the real developers/users will just continue working as normal.

(and I bet many find my post old and tiring! it happens in most thread a few pages down...)

I don't know, I tried QT several times, no use. Maybe I'm too dumb for it (and the whole C++ thing). I always failed somewhere, don't know why. For GUIs I always take GTK/C or GTK/Py - I like it, but tastes are different and I really don't want to see anyone coding MFC. Now THAT is a pain in the ass

As for Glade-3, I recompiled it. Played with it several minutes and found several ahas - the signal window has now better usability, the GUI is polished and several other nifty things. As for those who will cry "Glade won't support code generation": learn libglade and use anjuta. Granted: there are no proper libglade tutorials out there, but these are two lines to load the xml file, too ^^

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

Well, everyone should use what he likes to. Neither do I use Gnome, nor KDE. Thus I don't have kdelibs

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? C is structural language! I tell you that - from programmer's point of view using C with object oriented programming is not natural. Better use Objective-C, C++ or whatever, but not C or Pascal! 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. And yes, comparing gtk+-2.8 performance and responsivles with qt's 4.0.1 - gtk looses! C doesn't help GTK+, it's the main problem of it's difficultness.
Right now I'm learning Qt, i am going to completely drop GTK+ and don't touch it ever. To be honest, i have never seen such nicely written, well documented and easy to use while being powerful GUI library like Qt before. It's like combining Delphi with C++, but it's damn fast and powerful.

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?

I often hear this argument in C/C++ flamewar. Probably it's the only good thing C/Gtk supporters could say about their language. Face it, the only binding actually USED in REAL applications is Python. And you have it with both Gtk and Qt. All the other bindings are a solution in search of a problem.
Oh, and BTW: have a look here: http://developer.kde.org/language-bindings/
what new binding do you need?

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.

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

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.

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.

OK, I've been using both GTK and Qt on linux and they both have their stengths. However, my question is how cross-platform are both of them? I've attempted to compile my code on linux/mac but what if I want to hit linux/mac/win with a FOSS package? For those of you out there who have used GTK/Qt on Win, how hard is it for someone who has never used that other OS from Redmond?

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.

I want to read your opinion about Glade3! Not your preference between GTK, QT or Cobol!

I'm programmer, I like QT, I like GTK, each problem has his best tool to resolv and everybody can have his opinion. But please everybody, stop to bitch about things you don't really understand (because we all know that zelot don't do anything usefull and are just dumb people)

Linux is *not* user friendly, and until it is linux will stay with >1% marketshare.

Take installation. Linux zealots are now saying "oh installing is so easy, just do apt-get install package or emerge package": Yes, because typing in "apt-get" or "emerge" makes so much more sense to new users than double-clicking an icon that says "setup".

User: "How do I get Quake 3 to run in Linux?"
Zealot: "Oh that's easy! If you have Redhat, you have to download quake_3_rh_8_i686_010203_glibc.bin, then do chmod +x on the file. Then you have to su to root, make sure you type export LD_ASSUME_KERNEL=2.2.5 but ONLY if you have that latest libc6 installed. If you don't, don't set that environment variable or the installer will dump core. Before you run the installer, make sure you have the GL drivers for X installed. Get them at [some obscure web address], chmod +x the binary, then run it, but make sure you have at least 10MB free in /tmp or the installer will dump core. After the installer is done, edit /etc/X11/XF86Config and add a section called "GL" and put "driver nv" in it. Make sure you have the latest version of X and Linux kernel 2.6 or else X will segfault when you start. OK, run the Quake 3 installer and make sure you set the proper group and setuid permissions on quake3.bin. If you want sound, look here [link to another obscure web site], which is a short HOWTO on how to get sound in Quake 3. That's all there is to it!"

User: "How do I get Quake 3 to run in Windows?"
Zealot: "Oh God, I had to install Quake 3 in Windoze for some lamer friend of mine! God, what a f--king mess! I put in the CD and it took about 3 minutes to copy everything, and then I had to reboot the f--king computer! Jesus Christ! What a retarded operating system!"

So, I guess the point I'm trying to make is that what seems easy and natural to Linux geeks is definitely not what regular people consider easy and natural. Hence, the preference towards Windows.

is there an argument on c vs cpp on a glade 3 thread, where the article specifically said that there is no c generation any more? glade gives you a .glade file, you use that with libglade on any language you wish. probably the most active gtk development atm isnt using c, its either mono or python.

qt designer is extremely nice and full featured. however, since i dont have qt installed on my computer, my tools of choice for linux apps would be glade and python with pygtk. i find glade an absolute joy to work with, and to be totally honest, all the complaints ive seen here are made by people who obviously have never used it, some who are obviously not programmers. as hard as it is, lets try and drag this back on topic.

Correction, Qt is GPL on all platforms (as of Qt 4), and is also available with a commercial license, so if you write commercial software, you pay and if you write free software you can use the GPL version. This is a great arrangement, in fact if it wasn't then people would just fork Qt GPL but the current situation is better. GTK is licensed with the LGPL license so that both free and non free software may be linked to it. In essence, the only license difference between GTK and Qt is when developing non-free software at which point TrollTech charges a per-developer fee.

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.

Just compiled and ran it. I can't seem to get any widgets in my pallette. Kind of weird. I can't even figure out how to create a window. I've used Glade2 to write basic interfaces. If I'm not doing something terribly dumb, they've got a long way to go to get this thing out the door. I'm optimistic though that work on the program is still moving forward.

By the way.
I hope gtkmm will have a autoconnect function in the future.
Until now glade is almost useless for gtkmm. OK, i don't have to code the layout. But i have to declare all widgets i want to use in my .h files, and the most widgets are active widgets which i have to use in a program. Than i have to pull every single widget out of the glade file and have to connect the signals by hand. This is so much to write and could be much easier if you compare it with Qt4 autoconnect features or gtk#.

Third Glade is really more usable now and goes in direction that makes it even more usefull. I loved it for layout managment - cleaner and easier to use and understand than any other gui designer i have seen.
There is my screenshot: http://fiedzia.homeip.net/~fiedzia/misc/glade3.png
Together with python gives comfortable tool. One thing worth to mention that is still not known for everybody is gtk-qt theme that makes gtk widgets look like qt, eliminating gui diversity.

Sure it does. The world isn't just black or white (although as a good story-teller Feynman often made you think it was. That way he emphasized the basic idea and made it easier to understand and more enthralling for the audience.).

Of course we could decide to build all bicycles made of wood. And those bicycles might even work to some degree! And some people might even argue that the design itself is the same. By rebuilding the whole bike using metal you even get exactly the same machine, so who cares?
These people might even argue that wood is a much more appropriate material to start with because it's available everywhere and for everyone. And even more exciting: using a knife and a saw virtually _everyone_ on earth has the appropriate tools and knowledge to craft such wooden bikes. Doing some research you will even conclude that using wood people were able to create _extremely_ sophisticated and impressive stuff.

But really, why should people reinvent the wheel and spend time on making wooden bikes and object-oriented designed C? Why should they disturb their work flow and concentrate on issues which are solved easily by using more appropriate tools which exist since long?

Of course you could argue that these people don't want to learn about new technologies and you could say that they are religious about using wood or C: But then it's CARGO CULT all over again ...