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

List:       koffice-devel
Subject:    Some thoughts about KOffice
From:       Hubipete <hubipete () gmx ! net>
Date:       2006-04-18 17:58:18
Message-ID: 200604181958.22752.hubipete () gmx ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


Hi list,
I will post it here as I don't know where to publish it else:

I wrote down some of my thoughts about KOffice internal architecture here. I 
hope they are useful and will come reality at least partly. Note that I don't 
mention Flake in my concept as I don't understand its purpose. Perhaps I even 
use the idea behind Flake in my concept.

The model-view paradigm is very well known and important so for KOffice there 
should be a very clear splitt of the data and the view(s). The data is stored 
in a container which might be an XML-tree for OASIS documents or something 
different. They all should derive from one class so that they provide the 
same interface. Note that I am not speaking of KoDocument. The container 
should only have the pure data and provide ways to act on it. A KOffice 
application has a stack of such data containers during runtime. For example 
when you embed a Krita image into a KWord document KWord will have two 
containers in its data-stack. They are not linked or containing each other 
during runtime which might be different after saving them into one file. But 
during runtime it is simpler to hold them separated as they can only be 
edited single. The only case which needs to edit both data containers is when 
you are moving a frame from a word document into an embedded slide for 
example. This is can be easily done by copying the frame.

Now let's talk about the view part. The goal should be to design a flexible, 
extensible and high quality rendering solution with a clear architecture.
The KOffice canvas should provide only one interface for each application. It 
should allow to put what-ever graphical content on the screen. In order to 
make KOffice a really integrated office suite it should make 
document-embedding easy.
Starting with the assumptions I act on the first thing to mention is the low 
level painting. I assume that KOffice will paint on a QPaintDevice. A widget 
to display it all or an other device eg a printer.
In my concept there are renderes drawing on the QPaintDevice. This are classes 
that implement the generation of graphical content. I was inspired by the way 
Qt's SVG classes are organized: There is a QSvgWidget, a QSvgRenderer and a 
document class QDomDocument. So we can use several render implementations for 
example QSvgRenderer, KSvg2 ( when it is usable ), the Krita renderer to meet 
the colorspace needs. For the future it is possible to use OpenGL based 
renderers and it is always simple to substitute the renderer used.
It is also possible to render to a QPixmap how it is done by most applications 
at the moment.

An other goal is to provide only one interface to all KOffice applications to 
put their contents on the screen. This interface is a part of the canvas 
implementation. It will mostly be used by the class managing the operations 
on the data in their containers. Or perhaps the data containers can also be 
tied directly to the canvas.
Objects can be added on the canvas and the change to them needs to be shown 
through the canvas. Adding an object means giving the canvas a reference on 
the data in the container and obtaining a reference to the canvas object. 
There is a linkage between data and view that is used to notify the view of a 
change in the content.
The canvas uses some "translator"-classes that take over the task of the 
translation from data format to a paintable format contained by a 
GraphicObject. This task varies from application to application for example 
KFormula could store the edited formula internally as MathMLDocument and the 
canvas will only be noticed on changes of that data. Then the canvas needs to 
"translate" MathML to a bunch of GraphicObjects. Or a Krita image with 
several layers is reduced to a pixmap that can be rendered and is contained 
as data of a GraphicObject.
You may ask who takes over the layouting which is giving all objects 
coordinates on the page, decide on which page they are and giving them the 
right dimensions. This is the task of each GraphicObject. They have build in 
rules how to layout their children and which dimensions they have. In general 
you can say that the GraphicObject's coordinates can only be changed its 
parent-GraphicObject but the dimensions only by the GraphicObject itsself. 
All GraphicObjects are treated equally on the canvas and are stored in the 
ObjectStack. This stack contains all object available in all data containers. 
There is only one canvas per application instance.

But what data does the renderer use to render? This is the point where the 
rendering part and the canvas come together. When a repaint is needed the 
canvas decides which objects to be rendered for example which page or part of 
an image needs to be repainted. This means that the canvas has also the task 
to organisate repainting efficiently. This implies knowledge of the zoom and 
shown objects. With those informations the canvas decides to repaint a bunch 
of GraphicObjects which means passing them to the renderer with the right 
instructions.

My architecture is perhaps to fine grained but I think this will make KOffice 
fast. With the right repainting mechanism the repainting is reduced to a 
minimum.
In order to optimise rendering a selection could result in a QWidget holding 
the selections contents and being moved. This might be especially useful to 
implement also things like action-icons displayed near the selection. The 
QWidget would have a transparent background and the renderer would draw on 
it. But note that this does not mean that the graphical object is taken of 
the canvas stack. It still exists as an object to be layouted the only thing 
is that a change on the selection's content will only result in a repaint of 
the widget. For the icons to be displayed real buttons could be used that are 
tied to the widget.

One point I'm not sure if my solution supports it well is video. But how to 
deal with a video inside KOffice. I think the best solution is to embed 
Kaboodle or an other video player to show it. Or perhaps KOffice could use a 
plain video-widget implementation without control elements and provide the 
latter itsself. This would allow a nicer GUI.

Note some other points:
In my picture "KOffice Application" stands for one application like Krita or 
KWord and also for the suite which I described in competition entry. As you 
can see there is no need to have a different structure for both approaches.

I always differ between editing an object's content and moving an object 
around. Editing a widget's content mean not to "destroy" the current layout.

When you have different views of the same document it is not necessary to have 
two different canvases. When you display the same word document scrolled to 
two different positions it still is only one canvas that directs wo different 
bunches of objects to the renderer.

The translator-classes might also use some classes that are thought to display 
things. For example Krita might use QGLWidget to make image operations with 
the help OpenGL.

["koffice_rendering_model.svg" (image/svg+xml)]
[Attachment #8 (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]