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

List:       koffice-devel
Subject:    Re: Proposal for splitting koffice/plugins/ dir
From:       Jaroslaw S <kexipl () gmail ! com>
Date:       2009-06-24 21:21:51
Message-ID: 56a746380906241421h39825ebar34e5a7f7e5ca8bec () mail ! gmail ! com
[Download RAW message or body]

2009/6/24 Marijn Kruisselbrink <m.kruisselbrink@student.tue.nl>:
> On Wednesday 24 June 2009 22:52:19 Thomas Zander wrote:
>> On Wednesday 24. June 2009 23.24.11 Jaroslaw Staniek wrote:
>> > 2009/6/24 Cyrille Berger <cberger@cberger.net>:
>> > > On Wednesday 24 June 2009, Adam Pigg wrote:
>> > >> If such a a plugin was moved out of koffice svn, into eg sourceforge,
>> > >> what difference would it make? the plugin would link kexi and kspread
>> > >> libs, and if packaged, would pull in the required deps.
>> > >>
>> > >> Ofcourse, im perfectly happy to go with whatever is the right
>> > >> solution, i guess we would need something in /interfaces to represent
>> > >> libkspreadcommon,
>> > >> precisely workbook, sheet and cell objects, loading and saving. Im not
>> > >> sure how this would work so im open to help on that :)
>> > >
>> > > If we are talking about kspread migration, the idea is to use libkodf
>> > > to generate an ODS file. While libkodf is currently limited to low
>> > > level handling, the plan is also to have higher level.
>> >
>> > Great, but this is not to-kspread migration, it's ods migration.
>> > KSpread migration is a feature that pushed data into a living kspread
>> > instance I have opened. Nothing like this is available for now I guess
>> > at app-independent level.
>>
>> What about having a flake shape that is embedded in kspread as 1 cell or
>> maybe a range of cells to show kexidb based data?
>>
>> I'd love to have some library that links to both kexidb and libflake. It
>> allows the user to type a sql query and shows the output on screen.
>> This fits the concept of only linking to one app and it allows kspread to
>> use that flake shape to represent one (or more) table-cell.
>>
>> This would essentially do what you describe.
> 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;
just be cause some things are made as floatable shapes it does not
mean every use case is like this.
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.

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?

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 KDE Libraries for MS Windows (http://windows.kde.org)
 http://www.linkedin.com/in/jstaniek
_______________________________________________
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]