Re: [gtkmm] Doing a 'catch-code' library for the propesed functionality cuts in SigC++

[MHL Schulze t-online de (Martin Schulze)]

Hi!

I'm really sorry being so destructive in that discussion. Still I want
to express my opinion about this plan:

The six little adaptor classes that are included in libsigc++ 1.1 at the
moment provide _totally adequate_ functionality for all situations where
you can't directly connect a function to a signal because of differences
in the number and/or type of arguments and/or the return type.

Even though I think of these adaptors as an integral part of libsigc++
I understand that inside the main library, they make it more difficult to
maintain. But: I STRONGLY OPPOSE THE IDEA TO _SPLIT_ THIS FUNCTIONALITY 
INTO
DIFFERENT LIBS. Maybe some users don't use adaptors at all, but those who
make use of them need let's say three out of six in one program - but for
each program three different ones. THERE ARE NOT _THE_ TWO MOST NEEDED
ADAPTORS THAT SHOULD STAY IN THE MAIN LIB WHEN OTHERS ARE REMOVED.

The ideal solution in my opinion would be to restructure the code: make a
subdirectory 'adaptors' that hold all six adaptors classes. As a temporary
solution that allows a quicker release we could have a 'libsigc-adaptors'
library.

A 'LIBSIGC-EXTRA' library, however, THAT HOLDS TONS OF OTHER STUFF like
Andreas proposes WOULD BE OVERKILL for all users that just want to use
adaptors. Maintainability might win but usability in my opinion suffers
from this plan!

Regards,

  Martin


Am 25.07.2002 16:54 schrieb(en) Andreas Rottmann:
> Hi!
>
> Due to the recent discussion of cutting down functionality of SigC++,
> I'd like to push the creation of the already mentioned SigC-extras
> library. Since I have already started a library that originated in the
> idea of extending libsigc++, suprisingly called libSigCX ;-) which is
> part of my Yehia project (ucxx.sf.net), I'd like to propose the
> following:
>
> 1. Create a new SF project, called libsigcx
>
> 2. Create a build infrastructure for the project in CVS
>
> 3. Discuss what parts of my libSigCX should go into the new project
>    (hopefully all ;-)
>
> 4. See what murray really throws out of libsigc++ and put in the new
>    project.
>
> 5. Document the added stuff (note that my libSigCX is already
>    documented, at least in part)
>
> I volunteer maintaining this project and do 1. and 2. right now, if I
> get positive feedback. Furthermore, I hereby would like start
> discussion on 3. Here is a cut from
> http://ucxx.sourceforge.net/docs/sigcx/sigcx_features.html#sigcx_features:
>
> Features:
>
>     * A full threading API, including classes for threads, semaphores,
>       mutual exclusions and thread-private data.
>
>     * A dispatcher class that provides an abstraction of a event loop
>       and a stand-alone as well as a GTK+ based implementation.
>
>     * A fully SigC++ compatible way of invoking slots in other
>       threads, including creating proxy slots that will invoke the
>       original slot in another thread.
>
> Regards, Andy
> --
> Andreas Rottmann         | Dru ICQ        | 118634484 ICQ |
> a rottmann gmx at
> http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
> Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD
> 5B62
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list