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

List:       kde-devel
Subject:    KPlugins - summary
From:       Vladimir Lobak <vels () vdo ! net>
Date:       1997-05-13 0:45:42
[Download RAW message or body]


  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) ?


--
#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]