No design sketches, but I am about ready to commit and then you will have
HTML API docs ;-) I have the feeling we are all talking about two different
types of plugins. The plugin mechanism built into the effects class itself just
loads a shared object file, resolves a few standard symbols, and adds it to a
list of available effects. The plugin mechanism that the KImageShop people seem
to be talking about seems to be a whole child application that uses either SysV
IPC or Corba to communicate.

On Tue, 01 Jun 1999, Carsten Pfeiffer wrote:
> On Tue, 1 Jun 1999, Mosfet wrote:
> 
> Hi,
> 
> (shouldn't this go to the kimageshop@kde.org list? -> Cc)
> 
> > The plugin mechanism is built into the effects class itself, not the
> > application. The application gets all the data it needs (such as plugin effect
> > name, etc...) by calling the effect class. All the application really needs to
> > know is the label of the plugin and how to call it. Since you give the methods
> > the canvas or pixmap when applying an effect, the plugin can get the rest of
> > the data it needs from that.
> 
> do you have a little design sketch already? Some modelling would be a 
> good thing for an application of this size. I'm really interested in 
> kimageshop and would like to help, but before starting to code, we should 
> have a little UML sketch or sth like that.
> 
> I already wrote down some ideas and relationships, when Matthias came up 
> with the kimageshop idea, but it's far from complete and I have no idea 
> of other people's design intentions.
> 
> Cheers,
> Carsten Pfeiffer
> -- 
> http://www.geocities.com/SiliconValley/1632/
--
Daniel M. Duley - Unix developer & sys admin.
mosfet@kde.org
mosfet@jorsm.com