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

List:       kfm-devel
Subject:    Re: konqueror/DESIGN
From:       Sven Radej <sven () lisa ! exp ! univie ! ac ! at>
Date:       1999-02-19 16:47:50
[Download RAW message or body]

On Fri, 19 Feb 1999, Waldo Bastian wrote:
(...)
>It would actually be interesting to be able to support the netscape
>plugin API in konqueror as well. Didn't have the Trolls something for this?

I was thinking about that before CORBA came in. 
supose that kfm wants to show image. It starts "kview -embeded"
With that switch kview knows it shouldn't make it's own window but provide
winIDs of *Bars and mainView. 

kfm adds those *Bars and main view to it's window.

How? comunication was suposed to be done via stdin/stdout. KTMainWindow could
learn to handle *Bars and mainView not by pointers but also by winID and
swallow them even when they are in different address space (other process).
 Basic IPC for gui (resize/move/isFixedSize and such commands) could go through 
stdin/stdout pseudo-IPC or through XEvents (XEventFilters needed in that case)

It is possible to do that in kdelibs without changing (almost) anything in apps.
This method would be (IMHHHO) faster and easier to work with then with KOM/OP.

All this could work only when server app (kfm) starts client app (kview).
Otherwise there is no way for two apps to talk to each other.

 But this is not needed now when we have KOM/OP.
(...)
>> Of course. It can show some progress indicator (in separate window or any other
>> way, but not in konqueror) And when action is finished - quit.
>
>Wow, if we manage to implement all this we really have a killer desktop.
And what did you expect? ;-)

--
Sven Radej     radej@kde.org
KDE developer   Visit http://www.kde.org

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