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

[Ionut Borcoman at home <borco mailbox ro>]

Karl Nelson wrote:
> 
> 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.
Why should simplicity imply slow code ? I agree that Visual Basic is
simple and slow. But Borland's C++ Builder is also simple but fast. And
if you want wrapper over wrapper over wrapper, what about wrapping gtk--
around vdk. Just kidding.

> 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++!)
Where can I learn more about profiling ? I used it when working with
BC++ 4.5, but missed since than. On Linux it's even worse (because I'm
new and have to learn so many other things :)
 
> 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 think we should wait for Mario: he said he will try to make some
gtk--/vdk mixed code. I would rather go for that. 

> > 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
Yes, a poll would be good. But not for choosing between vdk and gtk--.
It wouldn't be fair. Vdk is not even beta yet. The poll would be good
for finding out how many C++ programmers are in the gtk+'s boat, how
many are using gtk-- and how many would like to see what vdk can become. 

I also think that, for the moment, the vdk team of coders is formed from
Mario alone (please correct me Mario if I'm wrong). I have just started
to make the tutorial and share my opinions about vdk with Mario, but
haven't make any real coding till now. So, why you gtk-- people are
afraid of loosing programers ? Do you already have this problem ? If
yes, than this means that vdk is really needed.

Ionutz