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

[Karl Nelson <kenelson ece ucdavis edu>]

> > 
> > How many layers do you want?
> > 
> > Just to bring up there is WxWindows/Gtk, although it has its own following
> > from WxWindows, a separate community which exists since 1993 (?) or earlier.

I think WxWindows/Gtk really doesn't share much to the discussion because
the focus of WxWindows/Gtk was to provide a specific interface WxWindows.
As WxWindows is a multi-arch framework this is a good goal.

> I think Andy made a point. I think that wrapper over wrapper over
> wrapper ... can just diminish the performance of the programs. This is
> one of the reasons why I've preferred for some times to use my own
> classes instead of some more powerful classes made by others, so
> powerful that they were too slow at what I've wanted (slow not because
> they were bad coded, but because they wanted to do so much beside what
> I've needed).

This is a good point. 
 
I suggested at one point that we create a stripped down version of
Gtk-- leaving only the signal frame and the most commonly used signals
and slots available.  However, most people didn't like the idea including
the mantainer, so it was dropped.  I would rather see that then
a completely new tool box.  (can anyone tell me how the signal frame 
differs from VDK to Gtk--?)   Considering the point of VDK is simplicity
and not speed I don't see where the VDK people would care if their signal
frame shared code with gtk--.   If you want speed use a thin wrapper 
(or none).   The point remains that a needless replication of widget 
code remains.

As for the all-too-powerful classes that are unusably slow.  I think
the development community would like to know when that is going on.
I have been working on the Gtk-- project soly to clear up the speed 
problems (and make the signal framework more readable and reliable.)
So few people actually profile their code to see were the time is
going that it is hard to say what is slow.  (Some people have called
the signal framework of Gtk-- too large memory wise.  Unfortunately
to fix this requires extentions not currently in C++!)

If someone is finding problems with my widget I would rather hear
about it then just suddenly discover a new one out there.

Agreed, wrapper on wrapper isn't the best. But wrapper over wrapper 
isn't necessary as long as one is coded with the other one in mind 
so there can be a switch off point.  Most of the wrapper could be one 
gtk+ but the fundimentals could share code. (again I don't know the issues.)

(I personally wrote a wrapper on a wrapper because that was the best
route for mantainablity.  My gtkglarea-- widget is a thin wrapper of
gtkglarea which is thin peice of code for transfering to OpenGL or
Mesa.)

Perhaps, all I really care is that the new one tie into the old one
somehow so that they can be mixed.  That will allow code reuse.  As
Gtk-- is thin merging VDK into it would be a bad choice.  On the
other hand tieing gtk-- into the higher level VDK might make sense.

> I agree with Guillaume here. The VDK and Mario really attracted me in
> the project. Maybe because it is a new one and I can take a closer
> look at how it grows and where it is heading.
>
I have found Tero very receptive to code changes just so long as
it doesn't break old code.  But then I understand that some would
rather start fresh.
 
Perhaps we can call for a tally of the actual numbers of C++ programmers
we have listening to this group.  Anyone got a poll site we can use? 

--Karl