Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)

[Michael Babcock <mbabcock la creatureshop henson com>]

Tero Pulkkinen wrote:
> 
> Michael Babcock <mbabcock@la.creatureshop.henson.com> writes:
> > I agree. We actually have three C++ interfaces to Gtk+ now: Gtk--,
> > wxWindows, and now VDK. I know it's easier and more fun to make your own
> > new interface from scratch than try to improve an existing library, but
> > it's less useful in the long run. Now I know, this is the Free Software
> > world, we're all friends here ;-) and anyone can do whatever they want.
> > But that doesn't mean we should eliminate criticism.
> 
> Well, if anyone knows better way to do something in gtk--, there's
> people that listen and help implement it. I have a feeling the most
> problem with gtk-- is that there's no beginner's documentation for
> gtk-- yet.
> (step-by-step tutorial has been started and it'll help about that issue
> - the parts I saw looked really great..)
> 

Thanks for your response.

Yes documentation is a problem, possibly the biggest. Not just
beginner's tutorial but the reference is incomplete. BTW the reference
manual on your web site hasn't been regenerated for a while.

There are some other problems I've had. Some could be classified as
problems with the overall Gtk/Gtk-- system, others are problems with
specific widgets lack of features. An example of the former is the
inconsistent method naming. Java class libraries used to be quite
inconsistent in the first version but they went through and cleaned it
up so that now often what you "guess" is the function name turns out to
be right. For example Getters and Setters aren't consistent in Gtk--,
sometimes starting with "get" or "set" and othertimes not. Another
overall problem is the lack of drawing functionality other than GDK,
which affects other things such as the horrible 32K pixel size limit on
Viewports. Java's Table widget separates the data model into a separate
user defined object, which seems much more flexible than the interface
that CList provides.

An example of hard to use widgets are the HBoxes and VBoxes. I'm not
sure if I'm just misunderstanding things from the documentation, but it
seems there is some confusion between functions that act on the boxes
themselves, and the pack_start function options, some of which seem to
set global box options and have nothing to do with the specific thing
being added. Again I'm probably misunderstanding it, but this was the
impression I got by just looking at the documentation, and not the
source. Fresco borrows the concepts of boxes and glue from TeX, and the
results are very flexible and intuitive. It's much easier to add the
right kind of glues than to figure out some bizarre combination of
options to get the right spacing and stetching/shrinking you want on
window resizes. Admitting I might be somewhat biased here because I was
already familiar with TeX boxes and glue. Fresco uses the
Subject/Observer pattern throughout its objects, Gtk uses it sometimes
(Adjustment/Range) but not others (Entry).

That's just off the top of my head. No, I'm not trying to be annoying,
I'm trying to help believe it or not.

> > So we have three interfaces and they all suck. Okay, that's a little
> > harsh, but they all _are_ immature. We don't have a single one that is
> > complete, mature, and flexible. It's great that one toolkit (Gtk) is
> > finally emerging as some sort of standard for Linux, but I worry that
> > the design seems a little... ad-hoc. I know it's easier to criticize an
> > existing design than to come up with your own, and I'm not saying I
> > could do much better, but in the case of graphical toolkits there is a
> > lot of good prior art out there. Look at Fresco, Java's JFC, OpenStep
> > for some ideas. Even check the Win32 widget API to make sure there isn't
> > something simple that it can do that your new Gtk widget can't.
> 
> This is why free software is superior to proprietary software. There's
> more than one or few people that can affect the design of any piece of
> software. If you know alot of better way to implement something than
> what is used in existing code, then you should tell it to people,
> maybe implement a patch to existing code and try get that patch applied
> to the "official" release - if that doesnt work, take the existing code
> and apply your patch to it and make your own package out of it.

Believe me, I know how lame it is for me to criticize design without
providing concrete patches. The usual excuses: not enough expertise to
completely design it myself without coding it along the way, not enough
time to code the whole thing. There is talk about integrating a drawing
kit into gtk-- on the gtkmm mailing list. Since the lack of OO drawing
functionality is one of my biggest concerns I will definitely at least
submit some of my specific concerns in another email soon.

> 
> (Actually, this is how I got involved with gtk--. I had been using Qt
> for some time, knew its strenghts(signal/slots) and weaknesses(widget
> ownership problems). There was some web page listing nice GUI
> libraries. Next to gtk, there reads "on the wishlist is a good C++
> wrapper."(1) and then link to gtk--. Figuring out how to make it better
> than Qt took quite some time, but the current design has many
> advantages over Qt's or gtk+'s signal system, and of course, some
> disadvantages too)

I absolutely agree with this. The event handling/callback mechanisms
(templated signal/slots) in Gtk-- are possibly the best of any toolkit.
You did a great job. BTW, I'm the one who wrote the Linux Journal
article you referenced on the Gtk-- page complimenting your signal/slot
implementation:-).

> 
> (1) The same web page still has that message, they did update the link
>     to new place though - there's still work to do, and hopefully the
>     message will encourage people to submit more patches :)
> 
> > Finally, a minor thing. Any thought of improving Gtk--'s name? As I
> > understand it, the person who initiated the Gtk-- project didn't like
> > C++ and isn't even working on it now. C++ users already seem to be
> > treated enough like second class citizens in the Linux/Gtk world without
> > a stupid name to rub it in. It also makes it harder to sell Linux as a
> > development environment to potential converts.
> 
> This can be considered if someone figures out good alternative and
> most people on gtkmm list agrees with the change.

Well an obvious suggestion is "Gtk++" (in fact I keep accidentally
referring to it as this when I talk to people about it). We have
libstdc++ so I guess `+' is a valid character in a library, so we
wouldn't have the "--"/"mm" discrepancy either. But we already have some
confusion about Gtk/Gtk+ so maybe some would argue against adding a
Gtk++.

--
Michael Babcock
mbabcock@la.creatureshop.henson.com