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

[Tero Pulkkinen <terop students cc tut fi>]

Michael Babcock <mbabcock@la.creatureshop.henson.com> writes:
> 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.

yup, I've had small problems with the machine where the web pages are,
updating them are quite hard currently, so I've only updated the "must-have"
stuffs.

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

Thanks for telling this, now that we know the problem, it can be fixed.
(I didnt realise we have this kind of problems :)

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

I think gnome canvas fixes this problem. (I believe it has
antialiasing and other goodies -- I never tried it though, but I've
heard _alot_ of good things about it.) For very low level drawing, gdk
is a good choice - and C++ wrapper for gdk's putpixel is probably not
what people doing low level drawing wants. There's also this gtk--draw
interface now, which hopefully helps with this problem.

I believe this problem is quite soon solved... Of course we're happy to
hear more ideas of how to improve them.

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

I believe CList interface was purposedly quite simple/little features
to avoid bad performance of what List widget had with alot of items.
How does the java version avoid that problem?

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

you're right. :) I still dont know too well how to use them. I think
for this reason gtk1.1 has Tk style packing stuffs implemented as some
widget. Gtk_Table widget is quite easy to use too - though changing
the layout is not too easy... :(

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

Do you know where is documentation how fresco/Tex boxes and glue works?
I should look into it more. (I remember looking at fresco a _long_ time
ago and it looked nice, but really slow because of all nice rotation
features and things like that => I didnt really take a good look :)

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

This is great. I've been wishing of more messages like this :) Its
really useful, makes the problems visible so that people can deal with
them. I'll put a list of the problems to web site to remind us what
needs to be fixed.

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

I've had the same problem lately :( Too little time to do things - but its
important to focus the little time we have to the stuffs that matters.

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

I'll look forward to hear of all problems people have with gtk--. (if the
problems are not visible, people cannot fix them..)

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

Though Gtk++ might be consistent with the previous naming of gtk..

Will have to talk about this with people doing gtk and other
parts of the system.

-- 
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --