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

List:       koffice-devel
Subject:    Re: Flakey Reports
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2008-04-27 19:47:04
Message-ID: 4814D838.2090100 () iidea ! pl
[Download RAW message or body]

Thomas Zander said the following, On 2008-04-26 15:59:

> I fully understand its a lot to ask; if you want to embrace the Flake 
> technologies you are also asked to re-learn how you solve certain problems 
> since the problems you are used to solving are different enough to not have 
> the same solutions you are used to.
> 
> Please don't dismiss Flake for Kexi, its the technology that binds the KOffice 
> apps together, after all.  But take your time investigating how Kexi can gain 
> from it.

I don't dismiss Flake usage in Kexi. Inserting flake shapes into reports and 
forms are well known TODO and sooner or later it will be there. But this has 
rather nothing to do with infrastructure controling the data flow and data 
processing. Sebastian explained this again regarding "kexi is not 
document/file-driven app" (neither is any app/lib based on kexidb approach).

For me, you're trying to put too much things to do in a single library:
"Flake, technology that binds the KOffice apps together, after all" is in 
other words a claim it can be a silver bullet, while it is simply not true. 
Sebastian has put the example with XML documents, that never existed and won't 
exist in technology Kexi is based on.

Note I still cannot see reson why KWord shouldnt perform rendering of 
full-page reports based on ODF templates. There is no need to duplicate this 
functionality in Kexi.

Again my claim that you extrpolate: "Flake, technology that binds the KOffice 
apps together, after all" - this would be changed to: "Flake, technology that 
binds handling of ODF together".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What I "dismiss" is a proposal of implementing data interfaces again (that's 
implicit result of the proposals, so please try avoid claims like "I have not 
proposed this" =) ). Seems that Cyrille received some useful knowlege on this 
topic thanks to patience of Sebastian. I appreciate their energy.
And I encourage to share some value called trust with others too.
Without this, for me, e.g. Adam would rather not use OpenRPT technology in 
reports, because it is 3rd party stuff, not 100% compatible with our 
asumptions about reporting.

There are many data interfaces in KDE, and there are also Qt-only, some of 
them are more or less created ad-hoc (e.g. the most ancient nearly all of you 
depend as user is KMail's internal one). Some interfaces emerged because a 
need for unification within a given framework, like the one (mentioned by 
Cyrille) in Plasma.
KexiDB has been created as interfaces and a set of common routines to address 
need for accessing and processing the rich abstract tabular/relational data 
for office apps. Nothing more. Using it in most reasonable places is a 
long-term proposal.
PS: Myself I believe in policy of not delivering half-developed features at 
all, so that's why I am very much accepting delays in delivering integration 
between data source providers (databases, spreadsheets) and office apps if we 
have no enough resources. But I am not accepting attempts for creating 
(oversimplified, I guess) interfaces again.
So, wrappers to simplify things - yes, redundant interfaces - no.

--
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
_______________________________________________
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]