Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)
- From: Guillaume Laurent <glaurent worldnet fr>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)
- Date: 14 Sep 1998 20:52:03 +0200
Mario Motta <mmotta@guest.net> writes:
> On Sun, 13 Sep 1998, Tero Pulkkinen wrote:
> >
> >Thin means it uses about the same abstractions as previous layer.
> >=> the implementation of it is simple.
> >
> i agree with this point of view, moreover "thins" concerns also:
>
> - memory occupation that can lead into "swap hell".
Having libs in the 1Mb range is pretty common these days, and it's of
little concern with dynamic shared libs. There's nothing we can do to
reduce Gtk-- size (we tried inlining and it made things worse), and
VDK will probably be bigger than Gtk-- once all the widgets are
covered.
> - memory leak due to fragmentation (so common in C++ when heavily
> use the heap like VDK and gtk-- i understand)
Having memory leaks has nothing to do with memory
fragmentation. Speaking of which, this excerpt from VDK's
documentation made me jump :
2. No memory freeing and/or deleting is requested, all new'ed objects will be automatically
destroyed at application termination (in future releases an interleaved garbage collection
will be provided).
> - machine load and others such things.
Lib size has little to do with machine load, and there is nearly zero
processing in Gtk--.
> >> - how is fast in signal dispatching ?
We don't care. Really. Signals mostly react to user's actions, and the
user can't perceive the difference between a 1ms reaction and a 10ms
one.
For an example of *really* slow "signals", look at Tk (pre 8.0
versions). There's no way we could be any slower than that,
implementation-wise, and Tk apps are still very useable, even on
"slow" machines. And with nowadays CPU specs race, today's "blinding
fast" is next year's "slow as an arthritic slug on spilled glue".
Signals don't have to be fast, they have to be flexible and easy to
use for the programmer. That's what matters most.
Now regarding VDK, and why I really want to convince you that it
should be rewritten as a set of Gtk-- classes. Consider
VDKPixmapButton. It's an almost exact duplication of a class I had
written almost a year ago, Pixmap_Tipped_Button (see my homepage),
which was one of my first try at Gtk--. I wrote it probably for the
same reason as you, because I needed the added convenience. Moreover,
it was much easier for me to write it than for you, because I was
already using Gtk--.
Gtk-- needs more high-level classes like VDKPixmapButton. Not only as
an added commodity, but also because they make great code examples.
--
Guillaume.
http://www.worldnet.fr/~glaurent
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]