Simon Hausmann wrote: Well, I can't build the thing, somehow the Qt CVS doesn't compile and I don't have the time to figure out why. > So this is no removal of an open desktop component standard IMHO, the > idea of components remains! It's just a matter of using fast and > efficient C++ interfaces First: Anything that improves the current (lack of) performance should be STRONGLY considered. It doesn't care if we're using a fancy internal structure and can communicate with the rest of the world if it is so slow that noone will use it. Remember, there were enough guys who whined that KDE 1.x had too much bloat... Second: The "yet another API" Openparts wasn't a very good decision. It's difficult enough for an "average" hobby programmer to learn Qt & KDE bindings.. Therefore shared libs is a very fast and easy solution, BUT - it likes to kill cross-language operation. Most other than C++ programmers won't have it easy to create a lib that could be loaded as a part, I think. AFAIK there are tools that can (almost) automatically create language-bindings for foreign languages to access c++ libs, but I don't know if they can work the other way, I mean create a language binding for a foreign language so that a C++ program could load it as a shlib. I don't think this works, but please correct me if I'm wrong. - it kills cross platform operation. The corba solution allowed (theoretically) to run a part on a highend-level-server and embed it's screen output as a Part into KSpread. This would be gone, I guess. A question: Is it possible with the canossa way to embed a window that was forwarded via the X11 protocol? If yes, the only thing that can't be done is the parts-specific toolbar/menubar ? Torben seemed to solve this via XML. So a part can have a static toolbar/menubar layout, but no dynamic (context sensitive) one? If this is no longer possible, then "the canossa way" would be a bad idea. The nice network-transparency of CORBA lacks encryption: afaik the datastream between server and client is not encrypted (?). Thinking about the information that could be transported via that channel, this is a serious security whole because anybody between could grab the stream and decode it. on the other side the shared libs solution kills the "multi threading" that was introduced by using CORBA. > (thus I fully support Torben's proposal) The ideal would be a very "thin" CORBA layer, so that the parts can still optionally run on a different machine ;-( -- Dirk A. Mueller