[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:05:33
Message-ID: 492258b10706220305h236cc559v8788bf708e8baa94 () mail ! gmail ! com
[Download RAW message or body]

2007/6/22, Thomas Zander <zander@kde.org>:
> On Friday 22 June 2007 11:23:32 Tomas Mecir wrote:
> > 2007/6/22, Thomas Zander <zander@kde.org>:
> > 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 ?
>
> The difference between KoPluginLoader based plugins and KParts plugins is
> not how heavy they are. I think there is no significant difference there.
> The main difference is the (programming) interface.

Looking at KoPluginLoader, it is just a wrapper for KTrader and
KService, able to load pretty much anything. So it should be suitable
for KSpread's needs quite well, whatever those needs are. Good, good.

> The stuff we use in Flake and in KoText is a combination of those two. The
> main concept is the object-oriented idea of programming to an interface.

Ah, so basically, instead of exposing the internal API to the plug-in,
creating a specific API for the plug-in to use, shielding it from the
app internals, while still keeping direct access a possibility. I like
that.

> I can imagine a (too simple) interface you create in KSpread.
> class KSpreadPlugin {
>   virtual Value value() const = 0;
>   virtual void setData(const QString &formulaText) = 0;
>   virtual QWidget* createConfigPanel() const = 0;
> };

Hrm. Well I guess you only use this as a generic example, as
reimplementing these functions would be of little use, unless you want
to have the plug-in store the cell data in a different way.

Perhaps I'm overheated today or something, but I'm still failing to
see any tangible benefit over simply allowing the plug-ins to set the
cell text, be it directly or through some proxy API. Unless we're
talking about big things like a plug-in using the cell to display
something totally different, not text, but that's likely going way out
of the scope of simple plug-ins, and should be done in a separate
flake.

Hrm. Maybe an interesting approach could be to maintain a collection
of objects that are "in charge" of cells. The default,
KSpread-provided one, would be the cell editor, but the user would be
able to change it to another data provider, which would be loaded as a
plug-in, and which would supply data in whatever way it wants - be it
database or that google example or whatever.

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