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

List:       koffice-devel
Subject:    Some random KOffice ideas
From:       Dik Takken <D.H.J.Takken () phys ! uu ! nl>
Date:       2006-03-25 13:08:38
Message-ID: Pine.LNX.4.64.0603251147360.27865 () venus ! phys ! uu ! nl
[Download RAW message or body]


Hi,

While looking at the latest Beta of KOffice 1.5, I was thinking a bit 
about the overall design of KOffice, embedded objects, and integration of 
multiple kinds of documents into one. Two ideas popped into my mind which 
I would like to describe below. Since I know very little about KOffice 
architecture, these ideas may be totally ridiculous and unrealistic but I 
wanted to post them anyway. You have been warned... :)

Idea 1 is about using GNUPlot as a charting backend for KOffice.
Idea 2 is about improving the integration of embedded objects in KOffice.

Idea 1:

Could KOffice possibly use GNUPlot for creating data plots? It looks like 
KOffice is currently trying to re-invent the graphing-wheel.

Maybe the output of GNUPlot it not hard to integrate into KOffice 
documents, because GNUPlot can render to various vector graphics formats, 
including SVG. I imagine the KChart part could use GNUPlot to generate 
an SVG graphics object and return it to the host application (KSpread, 
KWord, ...). The host application can freely render, scale and rotate the 
SVG graphics without having to call KChart to do this. Only when the 
settings of the graph change, or the data in the graph changes, a new SVG 
object needs to be generated.

Also, it might be possible to allow the user to convert a KChart object 
into an ordinary SVG graphic. This can be useful for customizing a graph 
using a general vector graphics KPart (Karbon?).

Maybe other KParts that produce vector graphics could also output SVG 
data?



Idea 2:

Idea 1 resulted in a second idea, about integrating KPart objects in 
KOffice documents:

It seems to me that it is difficult to achieve seamless integration of 
KPart objects into the host document, because neither the KPart (KChart 
for instance) nor the host application (KSpread for instance) knows what 
the complete document looks like. The embedded objects are seperate 
worlds on their own. Making the entire document, including KPart objects, 
look like one consistent Work of Art can be a bit of a challenge. Getting 
operations like scaling of objects work smoothly can also be tricky, I 
suppose.

(Please correct me if the above is not accurate)

The idea is to solve these issues by making sure that the host application 
knows how to render the entire document, *including* the embedded objects. 
The only thing the host application has no knowledge about is how to edit 
the embedded objects. This is left to the responsible KPart.

Since KOffice is now using the XML-based Open Document format, how about 
the following approach:

* All KOffice parts present their content by outputting XML or SVG data. 
In any case something that can be rendered without knowledge about the 
KPart that generated it.
* The host application will request the XML/SVG data of an embedded object 
only once, and use it to render the object when needed. Updated XML data 
of an embedded object is requested whenever the embedded object has been 
edited by the user.
* All KOffice parts use the same KOffice-wide XML data rendering engine to 
render the XML data to screen or printer. The rendering engine does not 
know which KPart generated the XML/SVG data, it can render it completely 
on its own.
* The host application will gather its own XML data along with the XML 
data of all embedded objects into one big XML document that is rendered by 
the KOffice XML rendering engine. The rendering engine does not see the 
difference between a KChart object, a KWord document, or a KSpread 
document with lots of KChart objects in it.

Maybe this approach will make it possible for KOffice objects to integrate 
better into the host document, because the host application is in charge 
of rendering the entire document, and it knows exactly what the whole 
document looks like. This may introduce new possibilities, like:

* Allow the host application to override the rendering style of the 
embedded objects. For example, the user could change the default font 
size/family/style of the entire document, including the embedded objects. 
This will make it much easier to create documents with a consistent look.

* Embedded objects can be rendered without calling the KPart. When a 
certain KPart is not installed (think of possible third-party KParts), it 
can still be rendered without problems.

* The user can save system resources by converting an embedded object to a 
general XML/SVG object that can only be rendered, not edited. All data 
that was needed by the KPart to edit the embedded object can be removed.

* Fast and smooth scaling/rotating of embedded objects, because the 
host application has all the information that is needed to fo this 
correctly. The KPart does not need to be invoked.

I know nothing about KOffice architecture or the plans for KOffice 2.0, 
and maybe some of these ideas are totally rediculous, but hopefully my 
input is appreciated anyway.

Cheers!

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