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

[Karl Nelson <kenelson ece ucdavis edu>]

[Other wrappers]

> >   ObjGTK - http://www.rit.edu/~waw0573/soft.html#objgtk
> 
> Dead link?

Guess so.  Was there and on freshmeat for a few months.

> >   SDPGTK - http://www.k-3d.com/
> 
> Their primary emphasis seems to be some sort XML deal; but the code is
> far more complex than Sugar. 6000 "grep ';'" lines of code, vs. 1400
> utterly trivial machine-generated lines for Sugar. Plus it doesn't use
> namespaces so you don't save much typing. :-) And I don't understand
> why their GtkObject wrapper doesn't do anything with the GtkObject
> refcount.
> 
> >   (and one other I can't find right now.)
> 
> I'm interested if you find it.

I had a list of all the gtk+ C++ wrappers, but I deleted it when 
I got depressed when it hit arround a page.  The point remains
there are way more than can be evaluated in a short amount of
time.  Most have died or been abandon but there is little way
of knowing that.  

 
> > They don't address the object creation deletion problem
> > at all.  
> 
> What is this problem? Sugar cleanly handles object lifecycle via the
> native GtkObject refcount I think.

This works well for some sections, but create those horrible bugs
in C++ peoples minds.  Remember how long I had to campain for
you to accept a nearly identical smart pointer system in gdk--?

There is also another problem of which gtk-- once had... disassembling
objects. 

void foo()
  {
    Gtk::Window w(Window::TOPLEVEL);
    w.show();
  }

void bar()
  {
    foo();
    Gtk::main();
  }

This situation can be very confusing.

ASIDE: you may want to consider another solution that gtk-- is
using for cheap wrappers.  This is to make the pointers equivent.

  class Gtk::Object : private GtkObject
    {
     Object();  // never has a working ctor.
     public:
       ~Object();  // dtor does nothing.
       operator GtkObject* () {return (GtkObject*)this;}
       Gtk::Object *create { return (Object*)gtk_object_new(); }
           /.../;
    };

the you use it with as a pointer with a pointer type..

  ref_ptr<Window> w=Window::create(Window::TOPLEVEL);
  w->show();
  Window *w2=w;  // copies without referencing.  

This will likely be what the rewrite of gdk-- looks like.
  

> Well gtk-- takes the approach of deciding on the minimal feature set
> (a complete C++-style interface with all the things C++ programmers
> expect) and then trying very, very hard to get that optimized enough
> to be acceptable. I think gtk-- does a good job. However, it
> invariably and inevitably adds a lot of complexity: things to
> document, things to have bugs, stuff to install, code to take up
> space, stuff to maintain, and a binding-specific learning curve. For
> many programmers this is worth it for the features, witness all the
> interest on the gtk-- mailing list!

Part of this is from your work before we added the new code 
generator.  Currently, Guallaume and I have been putting just
above token time into mantainence because it was all folded into
a generator much like sugar.

You are right about the philosophy.  We are optimizing the hell
out of the code base while adding things that C++ programmers
expect.  The end result is that we are driving the cost slowly
toward zero.  The closer we get the less need there is for
a binding like Sugar.  (except the all in header and no install)
Since I am constantly campaining to get the "features" of gtk-- 
in abstractions and use pushed back in the gtk+ level the difference 
between the two would be small. (inline header would be only difference.) 
Ie.  I am trying to drive gtk+ to be more C++ friendly internals to
reduce the need for such pain in the gtk-- level.

The only features gtk-- has are
  - flexible C++ signals
  - inheritance 
  - overriding gtk+ internals with virtuals
  - STL list interfaces (recent)
  - interactions between C++ and C memory models
  - method calling (language sugar)

If some decided Sugar was good started writting and then wanted
to add some features or deinline it, how close would it fall to
redoing gtk--?  Every C++ coder I have talked with that started
by using gtk+ and trying to use static callbacks, has told
me that it was a mistake because they inevitable recreate
gtk-- not quite as well.  They either end up throwing away C++
or writting their own mini set.  

(I noticed Guppi went completely away from C++ recently, but haven't 
followed the reasons.)

[...]  
> In any case I think the people that might like Sugar aren't using
> Gtk-- now so there is not a real competition between Sugar and Gtk--.

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

So long as people understand that sugar is not a C++ replacement
for gtk-- and that it should not grow into one it is likely fine.
I fear though that the first large project that uses it would
just end up changing it into a gtk--.

--Karl