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

List:       koffice-devel
Subject:    Re: kspread plugins?
From:       "Tomas Mecir" <mecirt () gmail ! com>
Date:       2007-06-22 9:23:32
Message-ID: 492258b10706220223k1708610cm72cda6101a7db9bf () mail ! gmail ! com
[Download RAW message or body]

2007/6/22, Thomas Zander <zander@kde.org>:
> KParts are useless for this kind of plugin, really.  Its not used in flake
> and the various other plugins in KOffice anymore. Only in Krita and other
> parts they are still used.

I'm not saying it's a great solution, just that it is somehow
possible, if someone really wants it :) Full KParts is way too
heavy-weight for a task like this, yes, although any form of plug-in
would still be using KTrader, which is a part of KParts if I
understand it right.

> This part;
> > > by having a way to hook a plugin into
> > > one cell so that one cell can use the output of the plugin.
> > > [This] means to define an interface with a way to get the
> > > value that will be used in the cell.
> is a better strategy where you have a much smaller API for the plugin to
> worry about and a lot more power at the same time since you require it to
> implement an interface.

How much interaction would be needed here ? I'm not sure if an ability
to hook a cell (or a range of cells) to some external plug-in can give
us any extra value that couldn't be accomplished by a simple plug-in
that implements a new function, which the user would then input into
said cell.

And if you want something more complex, wouldn't you need GUI and
things ? And if you do need GUI, isn't the whole thing becoming
heavy-weight enough that you may just as well use KParts anyway ?

Basically, I can see two ways for plug-ins to work:
- simple services loaded using a trader query and such - same as flake
tools and whatnot are loaded. They'd be able to link to
libkspreadcommon, and thus be able to register functions, access cell
data, modify them, and so on. Ability to react on events would be
limited, although adding a couple of signals here and there wouldn't
be too hard.

- a full API in the Cell object and such that the plug-ins could use
to take over cells and use them for their own purposes - the database
displaying comes to mind. While this would be possible with the simple
version as well (the cell objects are all accessible), the full API
would allow better reaction on events like the user clicking on a cell
and such.

As it seems, the question is whether the full API would be worth the
effort. That is, what kind of plug-in would benefit from having it, as
opposed to being simply able to access and modify cell contents and
define new functions.

/ 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]