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

List:       koffice-devel
Subject:    Re: Berlin Sprint Action List Update (2)
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-11-08 20:16:28
Message-ID: 200711082116.28661.mail () dipe ! org
[Download RAW message or body]

Sebastian Sauer wrote:
[...]
> and what happens if we need to share a KoStyleManager instance like e.g.
> we need for the header+footer within KWord (see
> KWOpenDocumentLoader::loadHeaderFooter ) or e.g. if we have 2 text-shapes
> within kspread or for nested shapes?

last 2 cases where meaned to be questions if such use-cases make sense at 
all ;)

> from the loading-pov atm;
> TextShape::loadOdf() uses KoTextShapeData to redirect the load-request to
> kotext and then kotext's KoTextShapeData::loadOdf() does the job to look
> if the passed KoShapeLoadingContext is a KoTextLoadingContext. If that's
> the case, we have everything we need (also a KoStyleManager) what allows
> us to easy pass shared loading-stuff (where atm the KoStyleManager does
> also match but is only one part) around... If that's not the case, the
> KoStyleManager is created on the fly (see also KoTextShapeData::loadOdf),
> used during loading and once loading is done, destroyed again (what is for
> sure dirty aka not optimal since everybody who likes to pass an own
> KoStyleManager to the loading code needs atm to create an own
> KoTextLoadingContext-instance and have to use that one as
> KoShapeLoadingContext, but that was the most flexible solution I was able
> to come up and it allows to full control the loading itself at any
> consumer of kotext).

I forgot to put it there the details why it was done that way;
KWord has another unique feature; frames... those is missing from the 
text-shape and only KWord knows about it aka is able to handle details like 
what to do with headers+footers.
That's why it was needed to provide on-top of kotext an application-depended 
way to decide what to do during loading (e.g. to be able to use KWord's own 
frame-code for headers+footers or anchors). So, all in all, it was needed to 
connect kotext, textshape and kword together in a way that allows other apps 
(like kpresenter or maybe even okular some day) to slip in between those 3 
components.
So, what we have in kotext so far is all the code we know about from the 
kotext-pov. On top of it sits KWord that does introduce then it's 
frame-functionality (that's why we have the KWOpenDocumentLoader 
specialization). Between both we have the textshape's which don't know about 
any details except how to render stuff and are controlled by the app aka 
KWord.
_______________________________________________
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]