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

List:       koffice-devel
Subject:    Re: kspread plugins?
From:       Thomas Zander <zander () kde ! org>
Date:       2007-06-22 9:41:20
Message-ID: 200706221141.20344.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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.


> 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.

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.

I'm sure this is a known concept. But allow me to go over it for clarity 
anyway.
KoTool, for instance, consists mostly of pure virtual methods. But in 
flake and in the other apps we use those methods anyway.  The methods are 
actually implemented in a plugin. And each plugin implements them 
differently.

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;
};

You can let Cell implement this interface and write a plugin structure to 
load different cell implementations using plugins. After which I can 
write a plugin to handle 'select a from b;' to make it query an SQL 
database.
Naturally you will need a GUI to set the cell type to a specific plugin 
and a GUI to setup the plugin specific things (which database to use, for 
instance).  That GUI will be code in KSpread and use the above API.


So, bottom line, its quite different from what you suggested and actually 
a lot simpler for the plugin writer (which is an admirable goal).
-- 
Thomas Zander

[Attachment #5 (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]