Re: dropping sigc++

Mark Thomas wrote:
> Before people start jumping to implement a c/perl/python/... client
> library, can I just suggest we keep it simple for now and just stick to
> the c++ one.  I've rewritten the C++ client lib once, and Andrew did it
> another time. I'd rather not have to repeat that work N times.  (Of
> course, if you really want to do it, then you're welcome to maintain it
> yourself).

Nope, C++-only clients are fine by me (for now).

For the curious (and I hope Mark will correct me if this is wrong): 
there would be no need to alter the server if the client library were to 
be written in C/Assembler/Java/Perl/Python/Rexx/COBOL/FORTRAN/APL; it's 
just that one of the hardest things to get right in a windowing system 
is delivering events to the clients, and using libsigc++ was a lot 
easier than DIY.

I reckon the time to write multiple client libraries is when the 
protocol is as near to v1.0-final as we can figure.  Even then we won't 
want to write very many tier-1 clients, as it's usually easier to 
maintain a Perl/Python/Java -> native-code module than to maintain 
multiple copies of the same code in different languages.  It often works 
out to run faster too.

While we're on the subject, if there are any Java programmers out there 
looking for something to do, it would be cool to know what needs to be 
there before we can port SWT (preferably to the level of "Fill in these 
10 native methods and it'll work").  Unless it's a simple as 
setPixel()/getPixel() it'll be a while before it's possible, but I would 
like to suggest we aim for the simpler of "Port FireFox" and "Port 
Eclipse" as the milestone at which Y next gets slashdotted.

Phil