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

List:       koffice-devel
Subject:    Embedding in KOffice
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2005-07-19 17:06:36
Message-ID: 200507191906.39805.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Most people will have seen my blog entry on embedding kparts in Krita already, 
but I always intended to discuss the topic here in a little more detail.

Basically, working through the embedding code for KOffice parts, and trying as 
many possible combinations of embedding documents in documents I came across 
the following problems:


* Scaling. Not many KOffice apps seem to agree about scaling -- this means 
that a KWord document in KSpread looks silly, and a Krita document in KWord 
ridiculous. The only things that look reasonable are kchart or kformula 
documents in KWord. I'm quite sure there has been a lot of discussion about 
this issue already because the code is littered with comments... I'd really 
like a solution here, preferably a good one, but any solution that's at least 
consistent would be a win... (And I think the solution should be based on 
real measures, as in "paint me you 2" wide document as it would look if blown 
up to 12", but I only need a 3" viewport on it" -- that should be doable if 
we decide to trust X dpi settings, and it doesn't matter much what internal 
resolution an application like KWord uses. But I have probably missed 
something essential here.)

* Pages vs Frames. Some KOffice apps see their documents laid out on pages, 
like KWord, Kivio or Karbon, others have a more freeform idea -- not really 
frames, but just a vast expanse of possibility: KSpread and Krita. I think 
that when embedding documents, the embedder should do the pages, and the 
embedded document should confine itself to painting inside a rectangle, 
without pagination.

* Framing vs stacking. I have this strong suspicion that KOffice was designed 
with KWord at its center... The basic KOffice part is a frame that gets 
activated on a double click. For applications with layers, like Kivio, Karbon 
and Krita this is inappropriate: we have a stack of layers, and the contents 
of a layer can be positioned anywhere in that layer. The layer gets activated 
whenever the layer is selected in the layerbox or through keys, not by 
clicking inside a rect.

* Transparency. That's another problem: I've found that most, if not all, 
KOffice parts don't honour the transparent flag (or perhaps the transparent 
flag wasn't designed for this...). I'd want any embedded part to paint only 
the non-transparent bits. Like the glyphs of a KWord document or a KSpread 
document. Is this something that can only be implemented with Qt4? 

* QDockWindows & their ilk. Karbon and Krita use QDockWindows a lot, Kivio its 
own style of dockers. I'm working on a library to unify them and to make sure 
docker positions get saved and all that. But perhaps that wasn't wise, and 
perhaps I should have extended KXMLGui with dock windows instead. At the 
moment, embedding a Karbon document leaves Karbons dockers displayed even if 
the embedded document is not activated, and that's messy.

I'm quite willing to start hacking on this; but it's perhaps an idea to spend 
some coordinated thinking & hacking effort on this during the Akademy hacking 
days? I'm in Malaga from Friday to Friday (when my plane leaves some 
ridiculously early time in the monring).


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