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

List:       koffice-devel
Subject:    Re: koffice reports
From:       Jaroslaw S <kexipl () gmail ! com>
Date:       2009-07-04 13:52:07
Message-ID: 56a746380907040652j3bb26cc9h6027eddf6061850c () mail ! gmail ! com
[Download RAW message or body]

2009/7/4 Dag Andersen <danders@get2net.dk>:
> Lørdag 04 juli 2009 12:10:53 skrev Adam Pigg:
>> Dag Andersen wrote:
>> > Earlier there was a lot of discussion on how to provide report facilities
>> > to koffice apps.
>> > Last night while watching a boring movie on tv I just thought maybe dbus
>> > could be used. That should get away with dependencies on
>> > internals/multiple apps, while still make it possible to utilize said
>> > internals, no? <disclaimer>I haven't used/investigated dbus much so I
>> > don't know it too well</disclaimer>
>> >
>> > What I was thinking:
>> > Implement a generic/empty interface in KoDocument that ensures a common
>> > interface for data extraction.
>> > Add dbus capabilities to Adams report generator/designer.
>> > Implement data retreival in the apps that want to provide this service
>> > (prob kexi, kplato, kspread, kchart)
>> >
>> > Am I on to something, or have missed a trick?
>>
>> I have no idea about your idea, but i was also having thoughts.
>>
>> I was thinking that the report widgets could move outside kexi (into /libs
>> or something) so they could be used in any app.
> Yes, this was my original expectation, but if (when) they are put into flake
> based shapes&tools I don't think it needs to be in libs. All access would be
> trough flake (which is in libs).
>> It would need some work to
>> make some interfaces.   Its currently abstracted away from directly using
>> kexidb, but still links to libkexidb and libkeximigrate, so would need some
>> more work in this area.
> If you want to access data from other apps, you need a way to get at it. One
> way *could* be by dbus, others have been discussed before, I think.
> Let's see what some of the others say.

Dag,
dbus is good for message processing, but experience tells me that for
data sharing it is not enough...

To see what are the differences between IPC and data exchange layers,
and what others did in the industry, you can visit eg.
http://en.wikipedia.org/wiki/OLEDB or
http://en.wikipedia.org/wiki/ActiveX_Data_Objects

It would be cool to have someone interested in this task.

PS (10th time?): Flake is bound to document-driven solutions, data
sharing (a core of cross-app reporting) is more low-level thing,
useful also for apps outside of koffice and apps not having a single
canvas.

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