On Wed, 8 Dec 1999, Simon Hausmann wrote:
> 
> > On Wed, 8 Dec 1999, Simon Hausmann wrote:
> > > > > > And btw (and offtopic), even for embedding I don't see why this should
> > > > > > necessarily be restricted to shared libraries. It should be possible
> > > > > > to write a proxy KPart which communicates with another application via
> > > > > > DCOP and embeds its window via the QXEmbed protocol.
> > > > > 
> > > > > It's not only about embedding an X11 window, that's no deal, yeah. The
> > > > > point about using shared libraries is that you can use the Qt action
> > > > > pattern.
> > > > 
> > > > Then this further rules out KParts for me. And furthermore, it
> > > > would be real license mess. I'm not going to put my programs
> > > > under the GPL just because some freaks use such viral licenses.
> > > 
> > > Sorry, but I don't get your point. (please help :)
> > > 
> > > What's wrong with using shared libraries, also in regard to the
> > > (excellent) Qt action pattern? 
> > 
> > It's a step back to the old days of DOS. Unix provides the
> > ability to protect processes from each other, and every
> > reasonable person makes use of this. Windows programmers
> > have waited long for this feature, and its lack of memory
> > protection is the greatest weakness of MacOS.
> 
> Protecting processes from each other doesn't help to solve the problem of
> embedding.

Talking to an application to open a file is not embedding.

> Just in contrary. As the old KOffice showed: Separating
> components in processes, for embedding, is less stable.
> (and DCOP wouldn't help here, as it's a general problem of distributed
> environments IMHO)

??? From what I remember what Torben said, the embedding
code was full of bugs. How can you take buggy code as an
argument against separate processes???

I use coprocesses all the time and in several programs
and it works very well and is ultra-stable. I have no
idea how you can say that there is a stability problem.

Bernd.