FW: why do constructors return GtkWidget?

Didn't mean to exclude the group from this.  Outlook, what can I say?

-----Original Message-----
From: Emmanuel Touzery [mailto:emmanuel touzery free fr] 
Sent: Friday, September 11, 2009 1:46 AM
To: Boggess Rod
Subject: Re: why do constructors return GtkWidget?

Well, although I agree with your conclusions, I don't agree 
with your 
reasoning.  Gtk+ is C, after all, not C++.  It's a romantic notion 
indeed to believe that if you make developers write the entire 
interface in raw, dynamic c-code that you'll somehow make or even 
encourage them to think.  Instead, all you do is make those that 
already think, work harder.
So you're advocating using gtkbuilder? I agree. I think you 
misread me.

I was actually talking to the others that think using GtkBuilder removes
them from the code.

Likewise, it's ridiculously unreasonable to assume that using the 
wrapper classes for C++ will somehow result in less efficient code.
This notion ignores the optimizations of the compiler which would 
result in almost the same code, short of a few 
nano-seconds.  And if 
you believe those nano-seconds lost to the end-user 
outweigh the hours 
spent by the future maintainer to stumble through even the best 
written code, you have a seriously warped underestimated 
value of your own self-worth.
So you maybe read that part that I'd rather not be behind 
bindings. It's not because of performance (I've written most 
of my GTK GUIs in
ruby-gtk2) but because I'm afraid of bugs in bindings 
(happened in ruby, when something fails you can never be 100% 
sure whether it's your bug or the bindings) and of new 
features not being covered and because it's more handy if I 
can compare with the mass of existing C code (the whole GNOME 
I'm considering gtkmm as I wrote in this thread but I think 
then I'll move all the way to Qt.
Also I'm using sysprof and I don't know whether it'll work with C++.

You're right, I misunderstood and misspoke.  Good reasons all to stick
with Gtk+.

However, historically in the C-language, one isn't required to cast 
upwards, only downwards.  It would have made more logical 
sense to me 
to have the widget returned as its native type, and force the 
developer to cast it downwards to a less-specific type.  
But just like 
everyone else here, I have a day job, and thanks to the wonderful 
folks that created and continue to maintain Gtk, I don't 
have to write 
and maintain separate GUIs for Unix, VMS and Windows.
We agree 100% here. Every word. That's exactly my point. If I 
didn't otherwise like a lot GTK and have a lot of respect for 
it, I would already have moved to Qt (now that it's LGPL) and 
forgot all about it.
When you buy a thoroughbred racing horse, they use a brand 
to mark the 
lineage of the horse, and it's placed inside the mouth 
along the gums 
so it won't be easily visible.  When someone is kind enough to 
generously gift you with a horse to speed you on your way, only a 
complete ingrate would look the gift horse in the mouth to 
see if it's a thoroughbred.

If you've the time and inclination to "fix" it, I doubt 
you'd get much 
resistance.  In fact, I'd be inclined to pitch in what 
little time I 
can.  But I would still encourage you to, instead, make use 
of the C++ 
wrapper classes.  I can't imagine why you'd think twice 
about it.  Or 
move away from the Gtk+ altogether, and create all new 
Gtk++ libraries.
It is possible to call C++ libraries from C, after all.  
I'd use them, 
if they'd let me compile cross-platform GUIs.
I'm seeing a lot of resistance in this thread. A lot. I 
didn't expect that. I honestly thought people would say "Yes, 
sure it's bad and we want to fix it for a while, maybe for 
Gtk4.x". This is not happening. 
And that's besides the huge problem of backwards 
compatibility. But even without that problem, I see people 
seeing that they don't want to change this.
What bothers me most is not that there is this whole API 
returning and taking GtkWidget* which in my opinion sucks but 
the fact that many people are happy with it and don't see a problem.

I didn't get the sense so much that there was resistance or acceptance
of the status quo, nor that there was a preference so much, but I think
to call it a "problem" would be overstating the case.  It works,
afterall, and has for years and in many lines of code.  We're mostly
discussing a syntax issue, and how a developer can make the most
efficient use of the compiler.  This is more of an "if I open my mouth,
I'll be expected to fix it" environment.  (hint, hint)

I believe what your sensing is a hesitation to commit to making a
massive amount of changes for what honestly would be minor gains to any
one developer.  And then there is that whole nasty business of backwards
compatibility to deal with.  I suspect if the developers of GNOME found
out such changes were under way, then you really would sense some
hostility.  And not just from GNOME -- there is a _lot_ of downstream

As has been mentioned on here before, it's not like any one group or
person is the gatekeeper.  If you make these changes to the source and
make them publicly available, it's more a question of whether or not the
public adopts your changes.

Besides, if I'm not mistaken, this is the application development list,
and there's another list for development of the solution.  Perhaps this
discussion would be better addressed on that list.  There's also a
feature request board, I believe.  If you put this up, let me know the
link!  I'll add my vote.

Making a new Gtk++ is completely out of the question, I 
explained why I'm not such a strong believer in bindings, 
however I downloaded kubuntu and may well give it a try, 
though I'm with GNOME since ubuntu 5.10 (was a KDE user before that).

Now I mentionned this pet project that I started in C/Gtk and 
it's over 5000 LOC by now. So I think I'll keep it on course 
and go forward with it. But this whole thing disappoints me, 
that some people even dispute whether it's good to use gtkbuilder.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]