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

List:       koffice-devel
Subject:    Re: kspread plugins?
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2007-06-22 13:26:47
Message-ID: 200706221526.52880.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 22 June 2007 10:23:20 Thomas Zander wrote:
> As loads of places now have plugins, I'd like to know what the kspread
> developers are thinking of doing the same for individual cells.
>
> Someone linked to this page on IRC;
> http://blog.outer-court.com/archive/2007-06-22-n66.html
>
> and its a perfect thing to have written as a separately installed plugin.
> Either by creating a new formula or by having a way to hook a plugin into
> one cell so that one cell can use the output of the plugin.
>
> The latter method means to define an interface with a way to get the value
> that will be used in the cell. I'd love to see something like that as it
> would be great to allow, for instance, a plugin that uses kexi to show
> the value in a cell based on an sql query (something a LOT of users have
> asked for over the years).
>
> Anyway, any kspread devs want to share their plans for this?  Maybe even
> give an opinion on what is missing to have this done in 2.0 ?

I've just integrated KChart into KSpread as a shape, as you might remember. 
For this, I used Qt's Interview framework (actually K(D)Chart already had 
support for it, so the choice was easy) and implemented a table model for a 
cell range. This is used by KChart to retrieve the data only, but it would be 
perfectly fine to provide models, that can also set data in a given range. 
The recently started (auto-)filter feature could also be based on this model 
approach. BTW, it is strongly coupled with database queries, at least in the 
OpenDocument representation.

The idea to provide an interface, that Cell implements will not work. Cell has 
become a short-living accessor to the data. Itself, it is not stored anymore. 
In Qt's Interview terms, it can most likely be identified with ModelIndex. 
The actual data (values, formulas, etc.) is stored in CellStorage nowadays. 
So, we would have to redesign too much to store at least the plugins 
inheriting the interface and reintroduce a
	Plugin* Sheet::cellAt(int col, int row);
method.

For charts I stored the model (located in koffice/kspread/chart) in a separate 
RectStorage (CellStorage::Private::bindingStorage) and created a very simple 
interface to KChart: KoChart::ChartInterface (located in koffice/interfaces), 
which provides only one (!) method to set the model. Actually, this interface 
belongs to KChart. The model is created on inserting the shape by 
reimplementing KoShapeFactory::createShapeOptionPanels().

A similar, refined approach could be used for KSpread plugins. The storage 
could be generalized to store generic models. And we could provide factory 
interfaces, that deliver config widgets and create the models.

Regards,
Stefan

["signature.asc" (application/pgp-signature)]

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