[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: dcop interfaces, standard ?
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       1999-12-08 17:04:12
[Download RAW message or body]



On Wed, 8 Dec 1999, Bernd Gehrmann wrote:

> 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.

Yes, sure. But I was never talking about that, I was talking about
embedding (as you can see in previous mails) .

> > 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 do not think that OpenParts was full of bugs (and I think I knew that
old framework quite well) .

> 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.

You misunderstood me. I definitely agree that using DCOP for general IPC
is cool, stable and fast (and HEAD shows that). I have not a single doubt
about that :) . But my argument about instability was referring to
full-fledged embedding (merging GUIs, providing an interface for changing
the GUI elements dynamically, etc.) .

Bye,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]