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

List:       koffice-devel
Subject:    Re: Proposal for splitting koffice/plugins/ dir
From:       Thomas Zander <zander () kde ! org>
Date:       2009-06-25 5:30:17
Message-ID: 200906250830.18196.zander () kde ! org
[Download RAW message or body]

On Thursday 25. June 2009 00.21.51 Jaroslaw S wrote:
> > Wouldn't this work better as a kspread formula plugin? (of course that
> > would first make it possible for a formula to show a result in more
> > than just the one cell the formula is in).
>
> Yes I guess you Marijn  got it right, there's no need for extra
> layers, especially gui layers;

Yes, I see your point.  It indeed does look a bit odd to have to paint your 
own value when all you are doing is working with pure data.
The topic of this thread, however, is to search for good solutions that 
avoid the mess found ourselves in in the past.
Lets constructively work towards that goal :)

> just be cause some things are made as floatable shapes it does not
> mean every use case is like this.

The point was more that it would avoid linking to kspread. Which is the 
important part. The fact that it would also allow you to access kexidb from 
kword / kpresenter / krita sounded like a great bonus to me.

> The main gain of having values (that come from db) anchored to cells
> is the "live data" exchanged between the two apps, available for
> computations at kspread level and kexi level, in parallel. As I can
> see it, this _may_ be beyond what floatable shapes or tools are
> designed for _now_. And that's not a problem of course.

A kexi flake shape would be live. Showing changes in kspread as soon as they 
happen on the database.
But, sure, I see your points. If you get around to implementing something 
like this, we should take a look at the libs to see if we can find a nice 
spot for this functionality.

> Cyrille just mentioned using flake is the way for use cases we are
> looking for; but I guess kspread does not renders cells using anything
> from flake? It's a completely different layer I guess?

KSpread indeed kept rendering of cells different. But flake shapes sit on top 
of it, so integration is surely possible.
I can see usecases for having kspread cell-anchored flake shapes. Adding a 
couple of methods to an interfaces/SpreadShapeBase.h class would allow this.

For example;
You create a flake shape that links to kexidb. It will represent data from 
that db.
You make your flake shape additionally inherit from 
interfaces/SpreadShapeBase
You create an interfaces/SpreadShapeBase.h file that describes an interface
like;
 virtual QVariant cellValue(int row, int column) const = 0;
 virtual int columns() const = 0;
 virtual int rows() const = 0;

Then KSpread should try to cast your shape to this interface and just show 
the data inline.

Naturally, this is an idea I had here in the last 10 minutes. You don't have 
to do it this way, its just an example of a possible solution.
The reason I write this email is basically to give ideas; you have lots of 
solutions available to make sure you get the features you want. The solution 
to link to two applications is definitely something we should avoid.

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