Smoke : KDE :: COM : Win32
Adam points out the deficiencies of Smoke as a language binding. On the whole, I have to agree with him. Smoke doesn't match what we should recognize as a real language binding.
Similar to COM in Windows, Smoke is an in-process automation system. Distributed Smoke (aka. DSmoke) would be a relatively simple add-on to the built-in marshalling system. The Perl/Ruby Qt interfaces are to the Smoke automation system rather than Qt/KDE themselves. It's analagous to a Win32 interface which only used CreateObject() and COM.
Adam goes over a list of what could be gained from having the ability to create real binding for KDE. However, it would likely require maintaining compiler support, and wouldn't be entirely portable to MacOS/Windows. I think Smoke is a necessary evil, while a real set of language bindings should be considered optional.
In short, worse is better.
Smoke is an automation system
Similar to COM in Windows, Smoke is an in-process automation system. Distributed Smoke (aka. DSmoke) would be a relatively simple add-on to the built-in marshalling system. The Perl/Ruby Qt interfaces are to the Smoke automation system rather than Qt/KDE themselves. It's analagous to a Win32 interface which only used CreateObject() and COM.
Adam goes over a list of what could be gained from having the ability to create real binding for KDE. However, it would likely require maintaining compiler support, and wouldn't be entirely portable to MacOS/Windows. I think Smoke is a necessary evil, while a real set of language bindings should be considered optional.
In short, worse is better.

0 Comments:
Post a Comment
<< Home