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

List:       koffice-devel
Subject:    Re: ODF text (was Release schedule after the alpha's)
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-12-23 17:11:12
Message-ID: 200712231811.12607.mail () dipe ! org
[Download RAW message or body]

Thorsten Zachmann wrote:
> I think it is wrong to have an KoTextLoadingContext. The way flake is
> designed it can't work that way. For me it looks like the only true reason
> the have a KoTextLoadingContext is a way to access the KoStyleManager.

and to pass on the KoTextLoader-instance... flake does not allow this 
otherwise then subclassing the context, or?
 
> I was just yesterday discussing with David a way to set stuff that needs
> to be available in shapes just after object creation. With that we can
> make it possible to set a KoStyleManager for text shapes by the
> application which would also make sure to have just one for all text
> shapes.

y, but odt-loading still would need additional state-details not covered by 
the KoOasisLoadingContext and not needed by !=odt.
 
> Also I think it is a must that the code does also work when no style
> manager is present for applications that don't need/want to support it.

y, and afaik that works already since KoTextShapeData does create a 
KoStyleManager+KoTextLoader if not passed in before already. Well, may an 
idea to move that logic to the text-shape itself...
 
>> 2) explain or refactor this confusing construct;
>> Constructor of KoTextLoadingContext;
>>    KoTextLoadingContext (KoTextLoader *loader, KoDocument *doc,
>>    KoOdfStylesReader &stylesReader, KoStore *store)
>> notice how you pass a loader there.
> 
> as said above I think we should try to live without it. If a
> KoTextLoadingContext is needed it should not be a derived from
> KoOasisLoadingContext.

hmmm... but loadOdf does only accept a KoOasisLoadingContext ... well, an 
alternate would be do let KoOasisLoadingContext inherit QObject and then a 
loader could attach it's state-infos there as properties...

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