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

List:       koffice-devel
Subject:    Re: Confused about plugins.
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2004-07-08 12:29:29
Message-ID: 200407081429.29875.boud () valdyas ! org
[Download RAW message or body]

On Thursday 08 July 2004 14:20, David Faure wrote:

> Hmm, are those plugins really KPart::Plugins?

Yes...

> If yes (which seems to be the case, if setInstance loads them), I'm
> surprised by the design decision (I guess you use a base class that derives
> from it, to have some custom API). For such handlers I would rather use a
> standard KTrader-based query (see
> http://www.klaralvdalens-datakonsult.se/~dfaure/conf/n7y/Trader/index.html
> for my talk about how to do this, if in doubt :).

Well, we started some time ago with a simple plugin that inverted images. I 
guess that would fit the KPart philosophy well. Then I realized that plugins 
couldn't reach each other's code, forcing us to partition cleanly, and that 
they compiled nice and fast, and that they could be used to dynamically 
extend Krita.

Which seemed a good thing me :-). And because there are quite a few things of 
which I want to have an open-ended list, from tools to colour models, I 
decided to use the plugins feature as much as I could.

Some plugins, like the image filters, only use Krita data, others, like tools, 
need have their internal state updated from Krita. So I did a little registry 
thing yesterday, but I fear I may have re-invented the wheel through 
ignorance.

>
> KPart plugins are meant for "3rd party" or "additional" features, often
> available via a menu item or toolbar button. Not really for core
> functionality.
>

There's the problem that we'll deliver some things -- like the ability to edit 
rgb or cmyk images -- with Krita, but that class of things needs to be easily 
extensible. After all, someone might just write an openexr image plugin if we 
make it easy enough :-).

> > And if there'd be a way to install Krita's plugins in a krita-specific
> > plugins dir, that would be nice too...
>
> I don't think it would be.
> Plugins need to be in share/lib/kde3 because they are executable code, and
> need to be in CPU-type-dependent directories.
> The rc file in the apps/krita/kpartplugins subdir already ensure that those
> plugins will only be loaded by krita. If you're worried about the namespace
> pollution in share/lib/kde3, well, ensure that the plugin names all start
> by "krita" :)

I will do that.

>
> > I'm afraid I've got both kinds... Perhaps I can set the instance name
> > different for doc and view?
>
> Yes, I was going to suggest that, but on hindsight I think your "handlers"
> shouldn't be implemented as KParts::Plugins.

I'll be a good boy and read about KTraders :-).

>
> Thomas Zander wrote:
> > Doesn't that mean that creating a new view (split view or just a second
> > window) will load the plugin yet another time?
>
> Well, that's wanted for plugins which affect the GUI (for instance the
> "insert scanned image" kpart plugins has an action that needs to be plugged
> into every view, so this is indeed the wanted behavior).

Ah, okay... But that's not needed for the tools, since they are created from 
scratch when the view is created through a factory.
-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]