Re: [gtk-list] Re: ANNOUNCE: Experimental C++ Wrapper

[Karl Nelson <kenelson ece ucdavis edu>]

> Karl Nelson <kenelson@ece.ucdavis.edu> wrote:
> 
> > The only features gtk-- has are
> 
> [...]
> 
> >   - STL list interfaces (recent)
> 
> Does this mean that I can avoid struggling with manual STL <-> GList
> conversion when doing a GtkCList of list<> (or vector<>) types?

Yes that and many other things.  For example, you can wander through
the gtk+ child lists as if they were STL.  You can even run GLists
through algorithms if you care to.  Every thing that could be modeled
by STL concepts is being converted to look like it.


> > I think that many people are not using gtk-- because of rumors
> > of instablity from days long past, foot print models from poor
> > compilers, competition between more wrappers than comunitee can
> > support, and advice being given by the gtk+ crew/users.  I am
> > not sure what gtk-- did to be so dislikely other than use C++ like
> > it was designed. ;-)
> 
> I use C++ with static call-backs because gtk-- was not stable when I
> started my project a year ago. Converting now would effectively be
> wasting time since my current solution is working.

Not that I am saying all codes should convert, but converting 
is not so painful as it appears.  I converted almost all the gtk+
tutorial examples in a night.  You can get a half ass conversion done
with a perl script, but as the real features aren't realized until
something is coded with C++ in mind it is as you say wasting time.

This is why the packer demo is my example or gtk-- in action

eve:~/cvs/gtk+-1.2/examples/packer> wc pack.c 
    664    1344   23305 pack.c
eve:~/cvs/gtk--/examples/packer> wc packer.cc
    453     924   12999 packer.cc

For large codes gtk-- has a source code compression of more than 50%.


> The fact that gtk-- is rumored not to work in Windows is one more
> reason for me to stay with plain GTK+, though I am not doing any
> Windows versions for now.

I am not sure where that rumor appeared.  Libsigc++, the signal
system which is the nasty peice to get ported, was done a long time ago.
Several people have talked about getting the port started on the mailling
list, but they have never reached momentium.  The only difficulty
at this point is gtk-- uses gtk+ 1.2 and will do so until gtk+ 1.4 is
stable.  (gtk+ windows version is tied to unstable 1.3)  If enough
people are interested in contributing, the support could get added in
short time.

Basically, gtk-- will work on windows once gtk+ has stable support
for window.  Sooner if someone wants to put in effort of supporting it.


> Also, I am a bit hesitant to depend on even more libraries, and
> finally I think the memory foot print looks a bit scary (though this
> is hard to measure with shared things, paging, and stuff).

What is an acceptable memory footprint?  Gtk-- is at ~48 bytes extra
plus a bunch of tables that may eventually get optimized out.  We were
terrifying at many K per object in gtk-- 1.0.2.  These have been solved
in our development which has been pushing stable for a month.  We just
lack man power to get it there more quickly.

I hope this at least encourages you to consider gtk-- for your next
C++ project.

--Karl