FW: why do constructors return GtkWidget?

["Boggess Rod" <rboggess corefurnace com>]

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?
>
> Hi,
> > 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 
> desktop).
> 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
impact.

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