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

List:       koffice-devel
Subject:    Text tool plug-ins
From:       "Tomas Mecir" <mecirt () gmail ! com>
Date:       2007-06-18 15:28:19
Message-ID: 492258b10706180828v276eff5csd3ae5835a720b886 () mail ! gmail ! com
[Download RAW message or body]

Greetings.

As you may know already, I'm mentoring the SoC project that aims to
create and text tool plugins for KOffice, KWord in particular. Fredy
Yanardi is the student doing this.

And it looks like we have stumbled across a problem with a design
decision that I'd like to discuss here a bit.

For the first "plug-in", the bookmark manager, Fredy has put all the
code directly into KoText / TextShape, so it's not a real plug-in.
This was done due to the need of having integration such as ODF
load/save, for which there are no plug-in hooks or anything (although
I guess moving the code out into some plug-in would still be an
option, if these hooks prove easy enough - of which I have my doubts).
This is not the concern at the moment, though.

The concern are the other plug-ins, as for these, I'd like Fredy to do
them as real KParts plug-ins, so that they actually -are- plug-ins, as
the project proposal says. And here lies the problem, for at the
moment, I'm not sure if there's any plug-in architecture implemented
within flake / kotext, flexible enough to do what's needed.

So the question is, what would be the best way of implementing such
plug-ins ? I see three possible solutions myself.

1. inherit from KoTool. There is a registry class doing a trader query
and everything, so starting this would be easy. However, KoTool seems
to be aimed at tools that get placed together into some palette,
selected with a mouse and used to manipulate objects. So unless the
class is flexible enough to allow tools that need to manipulate the
text (and possible other flake objects, as I would prefer not to
restrict this to TextShape only if possible), without being placed
into a regular tool palette, but using menu items imported through
XMLGUI

2. inherit from KoTextEditingPlugin. Again, the trader queries and
such are already implemented, but the problem here (apart from being
limited to KoText only, which is probably not avoidable in any case)
is that the KoTextEditingPlugin seems to be aimed for plug-ins that
need real-time updates about the status of the text. The plug-ins done
in this project do not need this functionality, though, for the most
part (the word count one does, but that's it).

3. Create a plug-in system ... probably in flake ? Or kofficecore ?
This would allow us to fine-tune the plug-ins exactly to the needs,
but it might take a bit too long, thus not fitting into the SoC
timeframe, and it also feels a bit like duplicating existing code, as
Flake tools and such already do possess dynamic loading and things.

Or is there some other solution possible, that I am not seeing ?

By the way, for the reference, the list of plug-ins that the SoC
project entails looks like this:
* Bookmarks plugin
* Uppercase Text (change text to all lowercase, title cased, or capitalized)
* Text replacement: Use thesaurus to do text replacement for similar
words, another example is text replacement by texting language.
* Colorization plugin
* An optional plugin that shows a word count in a docker

I hope there is some easy answer to all this that I just don't see :)

/ Tomas
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]