On Sun, 29 Aug 1999, Carsten Pfeiffer wrote:
> Hi,
> 
> I'm still some sort of a rookie concerning CORBA and KOM and how it
> is/will be used in KIS, so I hope someone can answer my questions here.

KImageShop is like every KOffice application an OpenParts application. OpenPart
are a layer on top of KOM handling the GUI stuff, while KOM implements
basic things like signals and events.

> Will every filter or plugin use KOM (I'll leave out the CORBA from now
> on)? That would mean, every utility function provided by KIS and used by
> the filter would have to have an interface in the idl, right?

Yes, we had the idea of using KOM for plugins and filters. But CORBA is to slow
to transfer large amounts of data (like image data). So we reconsidered and IMO
we should simply define a normal plugin/filter interface and put them in shared
libs. But I still think we should use KOM to make things like the a gradient
editor available for other apps.

> Small example, at the moment there is no interface Brush in the idl, so a
> plugin couldn't use any brush right now, correct?

You are right, a plugin interface based on KOM would require KOM interfaces for
brushes, channels, layers, etc...

> Wouldn't that also mean, that many config-options would have to go
> into the idl, too? E.g. a plugin would want to know the tiny font
> configuration as well as accelerators, current colormodel,
> foreground/background colors, etc.?
> 
> What about libraries? Will some stuff, not done via KOM be accessible via
> a kis-library? E.g. some custom kis widgets usable for plugins.

Hm, you are right, we should put custom KIS widgets and classes plugins may
want to use in a shared lib later. But let's implement a plugin system first.
;-)

Greetings, Matthias

--
Matthias Elter
me@kde.org / me@main-echo.net
KDE developer