Re: Proposal: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

In message <19990709084338.A12272@email.mot.com>Kurt Granroth writes
[...]
>
>I asked Mosfet about this.  He says that his comments were in the context
>of the Harmony code.  Jo Dillan and himself were proposing a "development"
>version of Qt that they could experiment with.  If their changes looked
>good, then they would submit them back to Troll under the QPL.

Yes, it was in the context of an experimental version of Qt and not
necessarily a stable version.  I offer libsigc++ to Harmony on many
occasions and only got one reply, (but the project was basically dead 
at that point.  (Mosfet indicated that he didn't see eye to eye with
Harmony developers, so I assume he wasn't talking about reviving Harmony.
But I may have missunderstood him.)

If a KDE developers cut is done, then I assume that if the
results are good that it would be resubmitted.  Regardless, of whether
the changes are done in an experimental version (which is how I do my changes
in Gtk--) or directly, changes fixes and conflicts will still need to be
resolved.  


>Now it was never the intent to change the signal/slot system at all.  I
>would be *very* suprised if Troll decided to go with a template based
>system.  Qt needs to work with a LOT of very mediocre compilers -- even
>ones that don't support templates at ALL.  

This part of the equation I have yet to see.  Qt uses templates as its
replacement for STL so I don't see it running on compilers without 
templates at least in not to the point that it will do any development.
And I originally rejected Qt because version 1.3.2 failed on all the mediocre
compilers that I had on my HP system.  (All 3 of them.)


>libsigc++ goes the other extreme
>and demands the absolute bleeding-edge compiler.  Being bleeding edge is
>fine for "fun" software.. but is not even an option if you want a
>cross-platform toolkit for business use!

This is a slight overstatement of the cutting edge of libsigc++.  The first
cut of it ran on such state of the art compilers as gcc 2.7.2.  (The
support was dropped because I the restrictions there do not represent
accurately those of other compilers.)  However, now the it is stable,
I have began porting back to mediocre compilers like VC++ 5.0.  Bad
compilers need some minor differences in template formulation, but
the user rarely sees it.  That is why I distribute seperate dists for poor
compilers that can't use the more general source.  I would be
curious to see the list of compilers that run Qt well but can't run
a libsigc++ API.  I suspect that it would be a rather small pool.

>HOWEVER, I forwarded the libsigc++ stuff to the signal/slot gurus in Troll
>for their comment.  It'll be interesting to see what they say...
>
>> One is that it is possible for libsigc++ and Qt signal/slot implementation
>> to coexist.  Libsigc++ is a very general mechanism and is enclosed
>> entirely in a namespace.  The only conflicts will be those macros
>> in Qt which may zap some of libsigc++'s words.
>
>This is possible.  I've been fooling around with using BOTH signals in a
>library I'm developing.  With a few changes to libsigc++, it has been
>working just fine (more on that later).

Okay, Hopefully the next version which is Qt aware will route around those
problems.


>> I have to believe that replacing STL with Qt types is a mistake, but
>> then it is your choice.
>
>The QTL (Qt Template Library) along with the QList, QDict, etc classes
>encompass much of the usable functionality of STL... but is MUCH more
>efficient.

Just curious, are there any benchmarks showing QTL performance against
some implementation of STL?  From my discussions with Arnt and my benchmarks,
I was under the impression that some part of QTL in the 1.x series was
too agressive about freeing memory resulting in slow performance. 
The bug is fixed not, but like one persons claim that "Qt is the fastest, 
most efficent C++ library written,"  I would need to see some proof.

(I don't particularly like some of the things I see in the SGI 
implementation of STL like a list mallocing 2 pointers on creation just 
to save 1 pointer in size, but overall the API has some potential.)


>In any event, the conversion from STL to QTL was trivial (a perl script did
>much of it).  If/when the STL ever improves, I imagine that converting back
>would be just as easy.

If the conversion is that trivial then that is the perfect place for a 
thin Qstd wrapper over the top.  If the names don't shift and it is 
just a change of namespaces it makes life a lot simpler, even if
there need be small differences.


>> Of course Gtk-- has less users and they are demanding the upgrade,
>> so we have less of a problem.
>
>Yep.  We are talking about thousands of developers that would be forced to
>change.  This is more than a technological challenge -- it is a diplomatic
>one!

Diplomacy is not my best subject.  (Damn it, I am a technologist, not 
a politician!)  I am not sure what mechanisms are best to find out
whether the change would be desired or not.  But discussion the pros and
cons is a good start.


>> However, the native signal/slots can not do 80% of the functionality
>> of libsigc++.  So the question becomes again what is needed.  If something
>> can be expressed as a few lines of libsigc++ and requires a hundreds of
>> lines to use the "native" signal that I would say not using libsigc++
>> would be the mistake.  (Of course, I don't know the depth of your
>> work arrounds.)
>
>Work arounds rarely take much code.  Also, since we are so used to Qt
>signals/slots, a lot of it is automatic.
>
>One "limitation" of the native slots is the inability to return values.
>However, return values are a legacy of synchronous programming *anyway*.
>With Qt programming, you learn to program as if everything was
>asynchronous.  It's tricky at first.. but once you are used to it, it's
>very automatic.

Libsigc++ is currently designed to be synchronous (which is like all
of gtk+). However, when there is no return code specified it could
just as well be asyncronous.  (Anything which looks like a signal
is a signal.  Thus the user can define their own signal class that
meets the API and the users would see it as just being another signal.)
The only delayed signal we have needed in
Gtk-- was the destroy one, but that has more to do with interactions
with the reference counted gtk+ object system than libsigc++.

It should be mentioned the libsigc++ return values go well beyond
that of just harvesting the last value.  The mechanism is user defined,
and the type used for Marshaling does not have to match that of the
return type of the slot.  For example the slot may return an int, and
the signal may return a list<int>.  This allows the user to do things
like take highest, abort on -1, form lists, etc.  Simply taking a
value is the weakest use of libsigc++. 

--Karl