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

List:       kde-core-devel
Subject:    RE: dcop interfaces, standard ?
From:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-12-08 10:22:09
[Download RAW message or body]

> On Tue, 07 Dec 1999, David Faure wrote:
> > I think that when one applications wants to use another one,
> > it should use KParts (the next one) and load the other app's shared lib,
> > instead of using DCOP - for the same reasons that we dropped CORBA.
> > And KParts provides open, close, save, ...
> 
> That's only true if you want to embed another application. For other
> tasks control of another application can be enough. For example in an
> IDE I would like to be able to load files in an editor, save them and
> set the cursor at the position where a compile error occured. It
> doesn't need to embed the editor for this.

Hehe, this is the exact example we had in mind when designing the new KParts
! :-)

Perhaps it would be a good idea to allow what you mention in KParts ? 
Using a component, but not embedding it. Well in fact it almost supports it
already.
You can use a part and not embed its widget. What might be missing is 
how the part gets its own window though.

Don't get me wrong. I agree that for talking to kmidi, DCOP is probably the
best
solution.
But for interaction between an IDE and a text editor... If you want to
have optionnal embedding, it's probably best to use KParts, which can do
both.
Otherwise you have to do everything twice (using DCOP when talking to a
different process, using KParts when embedding) - exactly what we wanted to
get
rid of when dropping corba.

Just my two cents.

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

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