First Development Version of Glade 3 Available
Linked by Eugenia Loli on Thu 29th Sep 2005 19:31 UTC
GTK+ 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.
E-mail Print r 0   51 Comment(s) http://osne.ws/9ad
Thread beginning with comment 38076
To view parent comment, click here.
To read all comments associated with this story, please click here.
rhavyn
Member since:
2005-07-06

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?

Reply Parent Score: 2

doug Member since:
2005-07-07

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

Reply Parent Score: 1

Read more of this thread... >
ma_d Member since:
2005-06-29

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

Reply Parent Score: 1

rhavyn Member since:
2005-07-06

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.

Reply Parent Score: 1