Re: Technical: Proposal: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

(I am writting from a text terminal, so I am just going to
hit the technical questions.  These are going to the libsigc
maillist as the info is applicable there.)

>Okay, now I *do* have some technical comments and/or questions.  These
>come mostly from my trying to integrate libsigc++ into an alpha library
>of mine.
>
>o It would be very handy if one could disconnect() all slots from a given
>  signal.  I noticed that you can do something like this with:
>
>  Connection c = signal.connect(...)
>  ..
>  c.disconnect();
>
>  However, AFAICT, this will will only disconnect this one slot.  It is
>  pretty much mandatory that I have the ability to disconnect a *specific*
>  slot from a signal or *all* slots from that signal...

Yep, this is a definite weakness of the API.  It should very likely 
get a empty() and a clear() method (ala STL).  I have debated
addind some iterator capablity, but as there is no way to
know what a slot is too it would be largely useless.

There is one technical challange to be addressed here.  How
to add clear and ensure it is not called from within a signal
emition process?  Currently on the slot being emited is allowed
to be removed.  Thus clear would either need a defered behavior
or an abort one.

(The lack of this is largely historical.  The proxy system
contained only those methods that we could do and could make
gtk+ signal system do.  Empty and clear were both beyond what
I have gotten gtk+ to do. However, I do not intend to lock
the system to mean exactly gtk+. Gtk+ has functionality that
is not useful for libsigc++ that I have skipped already.)


>o The 'emit()' function in sigc++/basic_signal.h needs to be renamed.  It
>  conflicts with the Qt emit during compilation.  I renamed it to emit_sigc
>  and it worked like a charm!

For the sake of a consistant API I would like to avoid permanently
renaming things like this.  I would like to have an emit method
if at all possible.  (We all call emit an emit!) The emit is there 
for one reason,  which is to provide a binding target for a
connect to signal.  This of course doesn't happen in the libsigc++
library at all so emit can be renameds anytime up til linking the 
application.  (Notation from one compiler to another on
operator() was so bad that I had to rename it.)  I could place
a SIGC_RENAME_EMIT switch and thus have it route arround the problem.
An alternative solution is just include libsigc++ first, users should
use operator() anyway. (Minor technical issue here, operator ()
should be an alias for emit, but C++ has no notation for that.  On
some compilers this results in an extra copy ctor getting thrown
in all over the place. emit saves one copy ctor on those compilers) 

BTW why does Qt use "emit" at all?  They are just deleting the word
and MOC doesn't use it (despite the documentation).  It serves no 
functional purpose what-so-ever as far as I can see.  (macros just 
to look pretty like that are a bit annoying.)  It you could just as 
easily undefine the emit and remove the dummy emits for Qt code using 
libsigc++.


>o Do you have a "canned" automake/autoconf macro for libsigc++?  Checking
>  for the library is trivial.. but finding the lib/sigc++/include path is
>  non-trivial and non-standard.  Do you have example code for this?

Yes, I included the sigc++.m4 autoconf macro which should do all of this
for you.  Also provided is the "sigc-config" script.  From those
I have spoken to, it seems that only the GNOME project uses -config
scripts which hold compile variables paths and other set up switchs
from autoconf.  When I started I believed this is the standard 
method just others tell me it is a GNOMEism.

(module autofig from the gnome CVS is a builder for such scripts but I 
don't know if anyone uses it.)

For quick compiles it is easier to just do

  c++ hello.cpp `sigc-config --cflags --libs`

And everything is done for you.  (I recommended it to the KDE
folks once but I don't know if anyone followed through.)  

The placement of the config header under lib is far as I know the 
best and most portable way to ensure that multiple compilers.
Working on the test systems with 3 different compilers, I find
it the only usable solution.  It is very confusion to those who
haven't worked on multiplatform or multcompiler filesystems.
(This is documented as a doc/FAQ, currently the only frequently
asked question!)

I will add my example autoconf usage when I finish documenting
it.

--Karl