--===============1062547498== Content-Type: multipart/signed; boundary="nextPart2349645.n0JAL6xmTZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2349645.n0JAL6xmTZ Content-Type: multipart/mixed; boundary="Boundary-01=_7iSREaVeg8t38pk" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_7iSREaVeg8t38pk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 hope they are useful and will come reality at least partly. Note that I don= 't=20 mention Flake in my concept as I don't understand its purpose. Perhaps I ev= en=20 use the idea behind Flake in my concept. The model-view paradigm is very well known and important so for KOffice the= re=20 should be a very clear splitt of the data and the view(s). The data is stor= ed=20 in a container which might be an XML-tree for OASIS documents or something= =20 different. They all should derive from one class so that they provide the=20 same interface. Note that I am not speaking of KoDocument. The container=20 should only have the pure data and provide ways to act on it. A KOffice=20 application has a stack of such data containers during runtime. For example= =20 when you embed a Krita image into a KWord document KWord will have two=20 containers in its data-stack. They are not linked or containing each other= =20 during runtime which might be different after saving them into one file. Bu= t=20 during runtime it is simpler to hold them separated as they can only be=20 edited single. The only case which needs to edit both data containers is wh= en=20 you are moving a frame from a word document into an embedded slide for=20 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= ,=20 extensible and high quality rendering solution with a clear architecture. The KOffice canvas should provide only one interface for each application. = It=20 should allow to put what-ever graphical content on the screen. In order to= =20 make KOffice a really integrated office suite it should make=20 document-embedding easy. Starting with the assumptions I act on the first thing to mention is the lo= w=20 level painting. I assume that KOffice will paint on a QPaintDevice. A widge= t=20 to display it all or an other device eg a printer. In my concept there are renderes drawing on the QPaintDevice. This are clas= ses=20 that implement the generation of graphical content. I was inspired by the w= ay=20 Qt's SVG classes are organized: There is a QSvgWidget, a QSvgRenderer and a= =20 document class QDomDocument. So we can use several render implementations f= or=20 example QSvgRenderer, KSvg2 ( when it is usable ), the Krita renderer to me= et=20 the colorspace needs. For the future it is possible to use OpenGL based=20 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 applicati= ons=20 at the moment. An other goal is to provide only one interface to all KOffice applications = to=20 put their contents on the screen. This interface is a part of the canvas=20 implementation. It will mostly be used by the class managing the operations= =20 on the data in their containers. Or perhaps the data containers can also be= =20 tied directly to the canvas. Objects can be added on the canvas and the change to them needs to be shown= =20 through the canvas. Adding an object means giving the canvas a reference on= =20 the data in the container and obtaining a reference to the canvas object.=20 There is a linkage between data and view that is used to notify the view of= a=20 change in the content. The canvas uses some "translator"-classes that take over the task of the=20 translation from data format to a paintable format contained by a=20 GraphicObject. This task varies from application to application for example= =20 KFormula could store the edited formula internally as MathMLDocument and th= e=20 canvas will only be noticed on changes of that data. Then the canvas needs = to=20 "translate" MathML to a bunch of GraphicObjects. Or a Krita image with=20 several layers is reduced to a pixmap that can be rendered and is contained= =20 as data of a GraphicObject. You may ask who takes over the layouting which is giving all objects=20 coordinates on the page, decide on which page they are and giving them the= =20 right dimensions. This is the task of each GraphicObject. They have build i= n=20 rules how to layout their children and which dimensions they have. In gener= al=20 you can say that the GraphicObject's coordinates can only be changed its=20 parent-GraphicObject but the dimensions only by the GraphicObject itsself.= =20 All GraphicObjects are treated equally on the canvas and are stored in the= =20 ObjectStack. This stack contains all object available in all data container= s.=20 There is only one canvas per application instance. But what data does the renderer use to render? This is the point where the= =20 rendering part and the canvas come together. When a repaint is needed the=20 canvas decides which objects to be rendered for example which page or part = of=20 an image needs to be repainted. This means that the canvas has also the tas= k=20 to organisate repainting efficiently. This implies knowledge of the zoom an= d=20 shown objects. With those informations the canvas decides to repaint a bunc= h=20 of GraphicObjects which means passing them to the renderer with the right=20 instructions. My architecture is perhaps to fine grained but I think this will make KOffi= ce=20 fast. With the right repainting mechanism the repainting is reduced to a=20 minimum. In order to optimise rendering a selection could result in a QWidget holdin= g=20 the selections contents and being moved. This might be especially useful to= =20 implement also things like action-icons displayed near the selection. The=20 QWidget would have a transparent background and the renderer would draw on= =20 it. But note that this does not mean that the graphical object is taken of= =20 the canvas stack. It still exists as an object to be layouted the only thin= g=20 is that a change on the selection's content will only result in a repaint o= f=20 the widget. For the icons to be displayed real buttons could be used that a= re=20 tied to the widget. One point I'm not sure if my solution supports it well is video. But how to= =20 deal with a video inside KOffice. I think the best solution is to embed=20 Kaboodle or an other video player to show it. Or perhaps KOffice could use = a=20 plain video-widget implementation without control elements and provide the= =20 latter itsself. This would allow a nicer GUI. Note some other points: In my picture "KOffice Application" stands for one application like Krita o= r=20 KWord and also for the suite which I described in competition entry. As you= =20 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=20 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 h= ave=20 two different canvases. When you display the same word document scrolled to= =20 two different positions it still is only one canvas that directs wo differe= nt=20 bunches of objects to the renderer. The translator-classes might also use some classes that are thought to disp= lay=20 things. For example Krita might use QGLWidget to make image operations with= =20 the help OpenGL. --Boundary-01=_7iSREaVeg8t38pk Content-Type: image/svg+xml; name="koffice_rendering_model.svg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="koffice_rendering_model.svg" image/svg+xml GraphicObject DataContainers Renderer Raster/ SVG KOffice Application QPaintDevice Printer/Screen Canvas ObjectStack renders an objectto a QPainter gives anobject tree translates object to graphics datawhich is stored on the have a linked representationon the "Translator" provides an interfaceand directs a givenobject to a --Boundary-01=_7iSREaVeg8t38pk-- --nextPart2349645.n0JAL6xmTZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBERSi+g+pIpXlyc/oRAuUFAJ9Wga1ZqhMh0mnLsymzXg97T2TE1QCgsIhJ euRepC15GWEtc+48zBPVqp4= =CGaG -----END PGP SIGNATURE----- --nextPart2349645.n0JAL6xmTZ-- --===============1062547498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============1062547498==--