From kfm-devel Fri Feb 19 16:47:50 1999 From: Sven Radej Date: Fri, 19 Feb 1999 16:47:50 +0000 To: kfm-devel Subject: Re: konqueror/DESIGN X-MARC-Message: https://marc.info/?l=kfm-devel&m=92386536625696 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