[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 10:58:44
Message-ID: 492258b10706220358s64aa8377h76a531ca6b71b3d7 () mail ! gmail ! com
[Download RAW message or body]

2007/6/22, Thomas Zander <zander@kde.org>:
> The basic Idea that I had is that KSpread should be able to ask the plugin
> for a new value whenever a recalc is done.

I see. This also depends on whether the value should update on -every-
recalc, or only on recalc involving that particular cell. Both
approaches would be possible, although the former might slow the app
down considerably if there are many values, or if obtaining the value
is slow.

The recalc manager currently doesn't support the former, although it's
likely in the plans (we were discussing this earlier, as some
functions such as RAND behave that way in Excel).

Anyway, I'm not sure if we need some GUI and whatnot for this
functionality at all, seeing that all this can be easily implemented
in a function, for which we could likely provide some abstraction in
the plugin API (although some objects would still need to be exposed -
Value/Number, the value converter, and such).

The time is always playing tricks on me, so I'm constantly finding
myself with less time for KSpread than I'd like to have, but I'll try
to implement this simple version of plug-in API sometimes soon. Would
be only the simple version where the plug-ins would be able to create
their own functions and such, but it can eventually be expanded to
provide GUI and cell hooks for easier updating if need be. The GUI, if
it ever exists, would be probably something like Cell / Show in cell
..., which would show a list of various things that can be shown in
the cell - outputs of various things, statistics and such - and
plug-ins would be able to add their own things there. Basically the
same as the functional approach, but more user-friendly.

> Another point that I should emphasize at this point is that providing an
> interface for the plugin to implement means that it is easier to keep
> your API stable because you can limit the (internal) classes you export.
> Which is great to allow an external party to write a plugin for 2.1 and
> still use it with 2.6 without recompiling.

Yes, makes sense.

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