Re: [Syllable-developer] Where we're at with desktop apps

[jamie c. <ju...@ho...>]

>From: Kristian Van Der Vliet <va...@li...>

>GUI's are inherently OO and Kurt wanted an OO language for the API.  At the
>time he started the only well supported, mature OO language in the 
>OpenSource
>space was C++.  So that's at least why lib[gui|atheos|syllable] is C++
>

Python, ruby, smalltalk, objective-C have been around for plenty long 
enough, and don't even get me started on Common Lisp ;)  And 'inherently OO' 
is a matter of opinion anyway (considered an event model or a constraint 
model?) , C++ is just terrible and C's only redeeming feature is as a high 
level assembler which has become the lowest-common denominator.

>Here's a the beauty of the libsyllable/appserver model: you don't need to 
>use
>libsyllable to talk to the appserver.  There is no reason that you must 
>write
>binding from $(LANGUAGE) around the C++ libsyllable API.  You can write 
>your
>own API in whatever language you want to use.  The only criteria is that it
>must be able to speak the same protocol as the appserver (Which admittedly
>may require some C++ to flatten and unflatten message data)
>

A good point, perhaps it might be possible to redo the lowest level of the 
messaging API in C and write a C++ wrapper on that for backward 
compatibility, but let other languages use the C API.  Then again, wrapping 
the C++ messages wouldn't be hard in any language since it's quite a 
self-contained component.

>The downside to this approach is that all of the controls are implemented 
>in
>libsyllable, and your new API would have to reimplement all of them itself
>(Look and behavour would have to match) so currently it may not be 
>practical.
>
>It occurs to me that the controls need to be pushed out of libsyllable and 
>put
>someplace where any API can access them.  Should we do that before Syllable
>1.0?  Well I can't really justify the work that would be required.  
>Designing
>a suitable system to do this and proving it with multiple API's is a big 
>job.
>

Exactly, the whole API is built on the C++ philosophy anyway, so there will 
always be contortions needed to work around it, the same is true for all C++ 
toolkits. I don't have the answers to how to solve these issues (look at 
Win32, it's a C API but still hideous to work with), I just feel there is 
some better way of building working GUIs  (I like NextSTEPs approach of 
downloading display postscript, just so you get a feel of where my mind is 
headed).

Don't get me wrong, this is just speculation, I'm not currently suggesting 
it is worth your time to attempt anything like this. However, by the time 
1.0 is available it will be far too late to go back and alter fundamental 
aspects like this.

>Have you looked at SWIG?  http://www.swig.org/
>

Yup, you can generate interfaces (as in my initial attempts for PySyllable) 
if the toolkit is written well (and the Syllable API is *very* clean) but it 
doesn't solve the main threading problems, this isn't Syllables fault but 
that of the language runtimes.  C won't automatically fix this but will 
remove the assumption most languages have that C++ virtual functions are all 
called from the same thread. Saying that, I do dearly hope that it's merely 
my lack of knowledge of Python internals that caused the bulk of the 
problems and someone can come up with an easy answer.

Jamie