Re: Proposal: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

My mailer screwed up and my reply got sent privately.  As
it was intended for the group I am forwarding it back to the list.)

------- Forwarded Message

> Before I get into the "meat" of this, I'd like to say that libsigc++
> is VERY nice!  I'm going to fool around with it in the next couple of
> days.. but I'm pretty sure that I'll love it.  Great job!

Cool.  

[...]

>> ...the possiblity of using Libsigc++ as a replacement for the Qt
>> signal system when the KDE coders make a developers cut of Qt
>> following the upgrades for Qt 2.0.
>
> This is a huge assumption -- that we will be maintaining a "kdeqt" or
> kqt or similar library.  This by NO means a guaranteed thing.  I will
> admit that there is recurring discussions about doing such a thing...
> but the signficant drawbacks to this (e.g., users can't use "stock" qt
> anymore, merging new features between qt and kdeqt would be a pain,
> etc) might be fatal.

Yes, this is definitely a prereq for merging qt and libsigc++.  This
was the method that Mosfet put forward.  I assume that if the
developers cut is good the improvements would be returned to Qt kit,
but this is not a sure thing (unlike our case where we control the 
code base completely.) However, I should say that it is not the only 
possible solution.  There is alternatives but they will sound a bit silly. 

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.  However, I would not
rule out that if you find some benifit to the libsigc++ library 
that it can't be made to work.  However, this of course means two
different syntax for signals.

A slightly more silly option is to use Proxies like Gtk-- does.  Since
gtk+ controls the signal system but using the gtk+ signals is a royal
pain from C++, we have to proxy.  A very thin automatically generated
layer could build a kqt wrapper over qt, thus avoiding mantainence problems.
Of course this makes the assumption both systems coexist.  

Again these are only possiblities.  More research or a more
knowledgable user would have to determine the feasablity.

 
> > There is of course benefits to the GNOME project for adoption of a
> > common mechanism for C++ callbacks between the two projects.  KDE
> > libraries that do not use the GUI can then become less tied to the
> > Qt toolset.  Thus projects can be ported from Qt to Gtk-- and back
> > again easily.[and so on]
> 
> In fact, nearly all of the core KDE libs make *extensive* use of Qt.
> Far from going away from Qt, we are integrating it even more.  For
> instance, we are in the process of replacing nearly all uses of the
> STL with their Qt equivalents (Qt is *much* faster and less of a
> memory hog).  Qt is much more than a GUI library and it shows in our
> libs.

I have to believe that replacing STL with Qt types is a mistake, but
then it is your choice.  One question, I would have is why not 
make a STL look a like over Qt and then forget that you are using Qt
types.  If they are close enough for the limited uses (after all
no one uses the full STL capablities), this could be an entirely inline
conversion.   I don't know the feasablity on that.  (Okay so I am
obsessed with wrappers...)  However, if that were possible one code
take code and compile with Qt or STL transparently.  (Of course
then STL could not be used at all when compiling with the Qt wrapper.)

It has always been my operating theory that STL implementations will
improve with time and thus become more accepted.  Also I have found
it just as easy to add new functionality over the top of STL, rather
than reimplementing it completely.  (The Gtk-- has had a horribly time
with NULLs and STL.)
  
It is of course my eventual hope there will be a object framework
which ports equally well to C and C++ that we could some day share.
(Gtk type system is currently no where close to that.)  However,
I think we can leave that for a long term pipe dream. :-)

 
> What this means is that even IF we switched to using libsigc++ in
> place of the native Qt signals/slots, you would still need to link to
> Qt!
 
> > Libsigc++ is very loosely tied to STL because of its Gtk-- origins.
> > I have no clue how much of an effect this would have on the process.
> 
> Well, as I said, we are moving to rid ourselves of the STL due to its
> bloat.  Maybe libsigc++ can be recoded to use Qt ;-P

My scans of my code (including unreleased code) show only one class 
which used STL more than trivially.  That is the need for the 
class map.  (And that is an implementation detail, unexposed to the user.)
All other STL sections were removed because of performance
problems with STL lists which allocated memory in ctor.  Assuming the
current trend continues it will likely get replaced as well.

 
> > Of course, the bulk of the work falls on the KDE codes to make
> > changes in the Qt library and the corresponding changes in their
> > libraries.  But then, I have already done 6 months of work
> > seperating the signal system from gtk-- so the task is considerable
> > simpler that it would have been some time ago.  As much of the work
> > can be done with a well coded script, it is certainly a possible
> > task if there is interest.
> 
> This is the core of it -- switching to libsigc++ would involve a
> significant amount of work.  I can see how scripts could lessen the
> problem (and some macro "wrappers" might allow us to leave some code
> as is, if we are smart about it).  HOWEVER, there are hundreds if not
> thousands of KDE apps out there -- they will ALL have to change to the
> new signal/slot mechanism.

It is definitely not a trivial task, however, the degree of change
is still quite small.

   emit signame(args);  
     <=>  signame(args);
   connect (this,SIGNAL(signame(int)),this,SLOT(foo(int))); 
     <=>  this->signame.connect(slot(*this,&foo));

Clearly, a 30 minute perl script could make such a replacement
so conversion would be significantly less.  This is exactly 
what we are of course forcing on our users as the pre-libsigc++
method requires almost the same conversion.

   connect_to_method(this->signame,this,&foo);
     <=> this->signame.connect(slot(*this,&foo));
   connect_to_func(this->signame,&foo);
     <=> this->signame.connect(slot(&foo));
   connect_to_signal(this->signame,signame2);
     <=> this->signame.connect(slot(signame2)));

Of course Gtk-- has less users and they are demanding the upgrade,
so we have less of a problem.


> Back again to the Qt issue -- maintaining a forked version of Qt would
> likely be a huge pain in the ass.  Changing Qt to use libsigc++ is
> probably one of the most drastic changes one could make as the
> SIGNAL/SLOT architecture is central to darn near everything.  That
> means that any further code merges (and there would be lots every time
> Troll released a new Qt) would likely have to be done "by hand" due to
> the complexity.

This I will defer to you on.  If they have used a good method
of seperating the implementation from the usage then it converts
to little more than the 30 minute perl script above.  If they 
have not it is a frigging huge pain in the ass!  (very likely
beyond worth doing.)  Clearly the state of the Qt internals 
weights heavily in this.

  
> The PITA factor here is so high that there would have to be an
> *incredibly* good reason to do so.  libsigc++ is good... but THAT
> good?  Hmm...

Here is depends on what the future holds.  If libsigc++ increases
in usage in other C++ libraries (which is the whole point of 
releasing it) then down the road it will pay off as the callback
method for those other libraries would be compatible.  If libsigc++
just remains as an application tool, then it very well may not be
work the pain.  This of course hinges on the existance of
good C++ libraries being linked by Qt using libsigc++, by no means 
a sure thing. 

 
> Also, for all of the advantages that libsigc++ has over Qt signals,
> you must realize that Qt signals do the job just fine.  We've done
> quite well even with the limitations... the added features of
> libsigc++ may well be nice and we might WANT them, but we definitely
> don't *NEED* them.

Yes, it has always been the case that one does not NEED the 
enhanced functionality of libsigc++ (if there were such a library
would have already been written.)  However, in this case, I
defer to what I have seen from my users.  Since I started this I
have seen users code doing thing with these signal/slot mechanism
that I wouldn't even dream of (stream overloading, properties, 
serial chaining, dynamic dispatch, and call once).  It 
is my opinion if it is there people will use it and to remarkable
things far beyond the distibuting of internal states as the
Qt signal/slot mechanism.  

Of course, depending on how your conclusion would have to
be based on what parts of KDE would be improved by such concepts.
The stange uses are based on the needs of my users and not the
other way arround.  (strange uses does not imply need)

 
> So the only real "killer" reason for libsigc++ would be the possible
> interactions between KDE and Gnome libs.  Unfortunately, the benefit
> here is still a bit dubious.  If you use KDE libs, you *will* have to
> link to Qt -- regardless of whether we use libsigc++ or not.  The
> argument could be made that you might as well use the "native" signals
> and slots, then.

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.)

 
> All that said, I really really like libsigc++.  I think I'll start up
> some discussion internally and see what happens.  We might be able to
> make this work, somehow.

Very good.  I do have my own doubts as to how feasible it
is even before I posted it.  I do not seriously think that if no
need is found or the job looks to be too difficult that it will get
done.  However, there is no harm in doing the evaluation.  If it
does turn out to be easy to do a worthwhile, then this discussion is
well worth the effort.

- --Karl