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

List:       koffice-devel
Subject:    Re: Some random KOffice ideas
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-03-29 8:09:45
Message-ID: 200603291009.45658.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 25 March 2006 14:08, Dik Takken wrote:
> 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... :)

Ah, well, don't be shy. You're one of our most long-standing and prolific bug 
reporters...

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

Actually, we're reusing a charting engine developed by KDAB -- no reinvention 
going on :-). I'm not sure what it is that the kchart engine outputs, but I'm 
fairly sure we'll be able to wrap it into a flake object so we can handle it 
transparently in all applications. Note that GNUPlot isn't under the GPL: it 
has a pretty unfree license: 
http://cvs.sourceforge.net/viewcvs.py/gnuplot/gnuplot/Copyright?view=auto.

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

That's the plan with flake.

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

Very tricky. This is one of the reasons for the flake effort -- we're trying 
to make more fine-grained objects that know how they want to be handled, 
together with a more unified tool system. This means that the main difference 
between creating a KWord document and a KPresenter document (for instance) is 
not in the kind of things you put on the page, but in the page, the user 
interface and certain application-specfic actions. But the actual objects 
that fill the page are common.

>
> (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.

Sure. We were moving somewhat in this direction anyway.
-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

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