Re: [gtk-list] Re: Drag and Drop, try 1

[Otto Hammersmith <otto redhat com>]

On Fri, Jun 13, 1997 at 06:10:02PM +0300, Martynas Kunigelis wrote:
> Elliot Lee wrote:
> >         I'm hoping to get Motif DND protocol docs and implement that.
> >         KDE uses Offix protocol version 0 as a base and then adds
> >         DndEnter and DndLeave events, making it Yet Another protocol to
> >         support.
> >         (this implementation is vanilla OffiX protocol version 1).
> > 
> Note that most probably KDE will use a different protocol in a near 
> future, since Troll Tech promised to add Drand And Drop to Qt 1.3, 
> which is promised to be released "in summer". Hope the Trolls will
> choose a good protocol, they always do the right thing programmingwise.
> If only Qt was LGPL!

Let's just hope they're bright enough to use OffiX. :)

> It would be nice, however, if gtk would support DND to/from KDE, since
> I (as many others) see KDE as a wide-spread desktop environment in the
> future.

Probably, will... though, it'll mean rewriting their libraries in C,
if they do something funky (i.e., non-OffiX-like). :-/
 
> Martynas
> 
> P.S. I don't want to start a flamewar, but has anybody asked why did
>      the autors choose C for gtk? I mean my heart hurts when I see
>      all the "C++ emulation" stuff. IMHO well written C++ code can be
>      as small/fast as C, and there's one BIG advantage that I see.
>      Here it is: I bet that every gtk_*_new() call returns a pointer
>      to malloc()'ed GtkWidget, right? Widget structures are pretty
>      small, right? The heap fragmentation gets pretty big, also the
>      overhead of having a lot of small heap chunks appears. Damn, 
>      testgtk eats 2M on my Linux system, where any of the Qt demos
>      eat about 1M (I'm not subtracting the shared lib size, I know
>      several apps would share it, but I'm taking a standalone app).
>      And with C++ you can easily create widgets on the stack or agregate
>      them into other classes. Allright, just don't start a flamewar,
>      that's just a simple $0.0002.

There's nothing stopping you from writing a C++ wrapper for gtk+.
There is no way for me to write a C interface to Qt... at least, not
easily.  Flexibitliy is a Good Thing (tm).

I won't get into the problems with C++ itself...

As for memory...

testgtk only eats just shy of a meg on my system, just after startup.
700k of that is shared.  That's nothing compared to Motif... not to
mention what happens because not everyone has Motif, static linking. :-/

Keep in mind, that testgtk has an awful lot of widgets, plus a pixmap
background.  I'd say it's pretty memory lean, all things considered.
Yes, it grows when you open more windows... I just opened every window
in testgtk, and got it up to just shy of 2M, 1.1M shared.  Is that how
you came to your number?  That's damned small!  I'd love to see the
equivilent numbers for Qt and Motif, if anyone has the time and
ability to do it. (I might end up doing it for my gtk+ article in the
LJ.. but I doubt I'll have the time to learn enough Motif and Qt to do
it.:-/)

I don't think fragmentation is going to be a problem for most
applications... if bunches of widgets are being allocated and
decallocated, the allocator probably will find a perfect fit chunk
from the last time it (or another of it's type) was allocated.
Something like gzilla might start having problem, since it will be
constantly allocating new and different widgets, but web browsers are
notorious for being HUGE... I'd bet that gzilla ends up being one of
the smaller ones.

I will admit the overhead of wasted space in small allocations is
something to think about... I believe S&P already are.

Okay, enough of my $0.02.

-- 
					-Otto.