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

List:       kde-devel
Subject:    Re: KPlugins - summary
From:       weis () stud ! uni-frankfurt ! de
Date:       1997-05-13 8:20:41
[Download RAW message or body]

Hi,


On Tue, 13 May 1997, Vladimir Lobak wrote:

> 
>   I've been away for a couple of days, so i couldn't reply to all the mail
> about plugins immediately. I'll try to combine all the ideas i got from you
> guys in this mail. 
> 
> 
>   Summary
>   -------
> 
> *  Runtime creation of plugin chains will be implemented, but i'll put it
>    on low priority right now.
> 
> *  Ability for application to provide data for first filter in chain (working
>    as input plugin) and receive data from last filter (output plugin). It
>    doesn't look like the right thing to me though. IMO it would be better if
>    app programmer created input and output plugins and distributed them with
>    application.
> 
> *  Mime type is used to identify data type passed between two plugins. We
>    must use as much standard mime types as possible. All other mime types
>    should be created using the form '<type>/x-kde-<subtype>'. E.g. 
>    'text/x-kde-directory'.
>    Association between mime type and file type (should be needed only by
>    input or output plugin, filters don't deal with files) must be global.
>    I.e. kfm may want to know about those association even if it doesn't use
>    plugins for some specific tasks.
> 
> *  Two ways to 'execute' plugins in chain: 
>     
>       a) Blocking - all plugins reside in one process and pass pointer
>          on data to each other. I leave this approach in hope that some day
>          we will have threads in Qt (Arnt !!! :)
> 
>       b) Non-blocking - every plugin resides in it's own process. IPC is
>          used to pass data between plugins. IMO this will slow down processing
>          when you have huge amounts of data to be passed through all the
>          chain (e.g. video). But this way has many advantages compared to
>          the previous.
>     
>     Both approaches use the dl* functions to load/unload plugins.
> 
> *  Plugin may be configured in three ways:
> 
>       a) Using get/set methods with option name and option value. App
>          programmer has to create his own config dialog for plugin parameters.
>          This may be useful if app programmer wants to provide some fancy
>          dialog with animated icons for e.g. some graphics filter.
>   
>       b) Calling the 'showConfigDialog' method of this plugin. It's not
>          required (IMHO) to implement this method in each plugin.
> 
>       c) Using the recent idea for automatic config dialogs. This way
>          plugin manager may automaticly create dialog for plugin that doesn't
>          provide it's own.
> 
> *  Plugins report errors/warnings/notifications to manager which decides what
>    to do next (may be user configurable) - e.g. abort chain, report to 
>    application, show message box, etc.. Manager should also abort chain if
>    some plugin crashed during processing.
> 
> *  API should allow filter to accept/produce more then one stream (have to
>    think about implementation). This is required for e.g. MPEG video stream -
>    somewhere in the chain (before decoding) you have to break this stream in
>    two parts - video and audio - and continue processing each part
>    in it's own node of chain. Similarly when you encode MPEG stream you
>    receive audio and video and after encoding each you have to interleave them
>    into one stream.
> 
> 
>   Release date :)
>   ---------------
> 
>   Plugins will not be released in the first alpha because there will be nothing
> to release actually :) I don't think we'll be able to release something until
> basic plugins (url input, audio output etc.) are finished.
> 
> 
>   Some notes about kmodules (proposed by Christian Czezatke):
>   -----------------------------------------------------------
> 
>   I still prefer to think of plugins as of 'data processing code'. They may
> have some limited GUI for presenting configuration dialogs or showing the data
> (output plugin), but please don't mix them with things like addressbook.
>   I do think the modular design is the Right Thing. But for things like 
> addressbook we can't use plugins. We need a completely different approach here.
> 
> 
>   The name of the project:
>   ------------------------
> 
>   I'm not sure it ML is the right place to vote, maybe it would be better if
> everyone who is interested in changing the name from KPlugins to something
> else will mail to me and i will post the results to ML.
>   Here are the nominees: :)
> 
>     1. KPlugins (no change)
>     2. MediaChain 
>     3. DocChain
>     4. You name it :)
>   
> 
>   Comments are very welcome.
> 
> 
> P.S.:
>    Could someone please post a short overview of kparts and kioslaves (other
> similar projects) ?
> 

kioslave is the IO process of KFM. KFM may run many of them. They
are connected using my special IPC to a server port in KFM.
KFM uses RPC ( remote procedure call ) to tell kioslave what to do
(copy files, delete files, etc. ).
Problem here: For every protocol ( ftp, http, tar... ) I get tons
of new code right now, since I have to write file->ftp, ftp->file,
http->file, ... 
That is no fun. In the future we would like to use plugins like this
( if this is possible )
I get the command: copy http://www.kde.org/index.html to file:/test
Now I start a HTTP input plugin and pipe it to FILE output plugin.
Right now it is not possible to copy from http to ftp direct
for example.

KPARTS
------

KParts are used to get something like openDoc/OLE. Every part is
a dynamic library. 
You need one KPartShell that provides a main window. All parts
share the main window, the menubar, the toolbar etc. KPartShell
cares about this. If the user clicks on a spreadsheet part then
the toolbar/menubar etc. of the spread sheet appear. Pressing on
a chart part will popup the chart programs GUI and so on.

It is possible that a KPart owns other parts. For example the
spreadsheet part may own a chart part that is placed inside
the table.

All parts have common functions not only for sharing window
ressources. They can print/load/save. I am using a Bento like
library that allows storing of any kind of KParts in one file.

You may have a look at koffice-0.0.1.tgz. There you can ( perhaps )
get an idea of how things work together.

KParts are the choice if you want several parts to share one GUI
and to load/save/print into one file.

Bye
Torben
 
> --
> #include <disclaimer.h>
> html *address(void) 
> { return Vels == (mailto:vels@vdo.net | http://aldan.ml.org:7000/vels); }
> 
> 

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