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

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

Thomas Zander wrote:

> On Monday 05 November 2007 15:46:07 Boudewijn Rempt wrote:
>> * all apps need the style manager, because now everyone crashes when a
>> new style is added, except KWord. It is a document-wide resource, so
>> KoCanvasResourceProvider is not the right place. Maybe KoDocument?
> 
> There are two things;
> a) it needs to be stored document wide

sounds like the most logical way imho :)

> b) it needs to be added to each QTextDocument instance used (in a kotext
> shape).
> 
> Storing it in the KoDocument is not going to be a good idea as that means
> it needs to link to libKoText. And it doesn't help anyway since the code
> to add shapes is not there anyway so point (b) can't be fulfilled here.

it doesn't need to link to kotext. Using a QVariant as container could pretty 
much do the job and only those that actualy need to work with it, need to 
link to it.
 
> Now, we can add the code to have a KoStyleManager in each app and add the
> code to the addShape of each app as well. But that means that app would
> immediately link against libkotext.

> So, my solution is a little added code to the text-plugin.  It will
> automatically create a styleManager for each text-shape that doesn't have
> one. Allowing the text shape to have styles.
> This, however, will not share the textstyles among all shapes in that
> document.  If an application wants that, he has to add the code in his
> document.

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?

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