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

List:       koffice
Subject:    Re: Plug-in structure for KOffice
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-02-19 14:09:59
[Download RAW message or body]

On Sunday 17 February 2002 20:14, Daniel Herring wrote:
> Although I've been lurking for some time, I don't remember KOffice
> plug-ins ever being mentioned.
> 
> If I'm blind to the current plug-in structure, please forgive me and point
> me to it.

There is a plugin structure, the one coming from KParts.
See the KParts tutorials to learn about it, and see koffice/plugins for very
few (a single one, actually) koffice plugins.
That's about plugins that add some functionality accessible by a menu item
or toolbar button in the KOffice application. Works for quite a few things,
but not necessarily for everything.

For instance, the mail merge functionality in KWord has a plugin infrastructure
too, but its own, since plugins obviously implement a very specific API.

> Otherwise,
> I was interested in writing some specialized math routines (polynomial
> fitting, singular value decomposition, FFT, ...) for KSpread, but feel
> that these would simply add bloat for the average user.  It would be
> better if the end-user could choose advanced functionality by installing
> extra plug-ins instead of having to recompile all of KSpread with the
> --feature-X flag set...

There's no --feature-X flag for that exact reason ;)

I'm not sure it's worth implementing a plugin infrastructure for KSpread
math routines. The code for them shouldn't add too much bloat,
and the XML file describing those functions doesn't have support for
multiple xml files to be merged at the moment. But that could be done,
of course - understand this as "if you do it" ;)

> In things like KWord, plug-ins could be used to enable/disable things like
> spell-check, auto-complete, auto-correct, and other "optional" behaviors.

Ah, that's another kind of plugin I didn't talk about yet (in this mail) :
data tools. See KDataTool (now in kdelibs/kio/kio).
There's already a spell check datatool, but only for kspread and possibly
other non-word-processor apps. In KWord more integration is needed, to
e.g. highlight the word being misspelled, etc.
Autocomplete doesn't exist yet, but could very well be done as a data tool,
I think. For autocorrect, some way of keeping the tool around would be needed 
though, since this happens on every keypress, so we don't want to recreate
the data tool each time.....

> This way, people can better customize their system.  Also, a good API
> should make it easier for people to write said plug-ins without having to
> delve deep into the workings of KOffice.
Yup. KParts Plugins are very easy to write, in general.
However, when the plugin does something specific to the app (e.g. accessing
KWords paragraphs etc.), some "delving" is obviously needed.

Data tools don't have access to the app's internals, they are simply passed
the app's data (e.g. the text), and can do anything with it, including modifying
it. But that's what limits data tools to certain uses only.

So... what do you plan to write, after all this ? ;-)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david, http://www.konqueror.org
KDE 3.0: Konquering the Desktops

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