Re: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

> On Sun, 29 Aug 1999, Karl Nelson wrote:
> 
> Karl, I said that some of the old Harmony people may get together and make
> their Harmony work available as QPL patches against Qt, and that would be the
> only place I could think of that would be appropriate for this kind of work. 

Okay that was not in your letters to me.  You simply said some developers
and named one of them.  I suppose I was supposed to guess what part
of the project they worked on.  Your only mention of Harmony was that
you did not agree with them on many occasions. I certainly agree the this is a 
experimental branch kind of thing.  I just need to know if
someone interested in making such a branch.


> I have no idea if this is going to happen (I kindof doubt it now), and I 
> *never* said KDE would necessarily use your library. 

I never believed that KDE was intending to.  I only thought that it
was KDE developers that may do the experimental branch and it 
was to them that I am offering the assistance.  Since no one in KDE
is interested in making an experimental branch there is no point in
discussing it at this time.   I made the proposal to see if there
was interest, but it appears there is not. 


> As of right now we are working hard on KDE2.0 and there is little likelyhood 
> of us switching our signal mechanism. 

Yes, I do understand that now is not likely best time for KDE, however, if 
someone is evaluating it, this is the best time for libsigc++ to make
changes.  My work on gtk-- is ramping up and my time will run short
as the fall semester begins.  Thus if there are interested parties
now it the time to get input in.  


> After KDE2.0 it would be up to you to 
> port and and show that it benefits real world apps (I spent a significant 
> amount of time explaining how I think it would not), and is as portable as 
> the QT mechanism.

No one here has heard any debate over the portablity of it verses Qt 
machanism.  Other people have properly pointed out that QT mechanism
is taking keywords and thus is very unportatable.  On the other hand
libsigc++ has been shown to run on all the compilers that KDE does
so I don't understand how the KDE folks should be concerned about
its portablity.  Since this has not been held in open discussion 
forum do you can to reiterate your objections here?  If libsigc++
runs on same places as KDE, how is it less portable? 

The uses in real world apps has already been shown as for as I am
concerned in Gtk--, Gtk-- using projects and Libsigc++ using
projects.  With the Libsigc++ methods, KDE would be less
bug prown, more debugable, and would enhance the possiblities
of the system.  I have stated numerous reasons for in earlier
thread, but no one has stated why this would not be the case.
If you have some reasons which you feel this statement is
incorrect, please give them.  Yes the current system is attiquite,
but the question is what benifit would libsigc++ have and would
those benifits rise to the level to make it worth it.  They may
not be but unless discussion is done, one would never know. 

I do not have the time to put in to rewritting Qt unless there
were significant help from interested parties.  As there are
none, I don't think it will happen.  Should KDE or others
decide to make an experimental fork, I would be glad to lend
advice and necessary changes to libsigc++.

Thanks for your time.

--Karl