[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-26 14:12:21
Message-ID: 200712261512.22043.mail () dipe ! org
[Download RAW message or body]

On Monday 24 December 2007, Thorsten Zachmann wrote:
> On Sunday 23 December 2007, Sebastian Sauer wrote:
> > 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 can't see right now why the KoTextLoader needs to be passed around. Can
> you tell me the reason for it?

1. The KoTextLoader does cache loaded styles what means just like the 
KoStyleManager got passed around, it's needed to pass the loader around. The 
caching is there since it improves loading by something like 50% or so and a 
few months back we (Pinaraf, myself and Thomas) decided to don't add that 
code to the KoStyleManager itself since it's only related and needed during 
loading and will be later added to the stylemanager.
2. Since each Shape does only provide those loadOdf - what includes the 
textshape - and since there was no way to pass in even more infos (like the 
current list-level and all the other things that are uncommented / not 
implemented yet), the context got introduced. This is needed since e.g. KWord 
does create own shapes for the header, the footer and the body and we still 
like to e.g. share the styles.

> You are right flake does not allow to pass around data. But also
> subclassing does not work as then the application creating the context
> would allways need to create the subclassed version which is e.g. not
> possible for the copy and paste classes that are in flake as flake does and
> should not depend on kotext.

The context is created on the fly if not passed as well (just like the 
stylemanager and the loader).

I still agree that the solution may not be the best one, but I still don't see 
a better one.

> > > 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.
>
> what do you mean by odt loading? Loading in kword or loading of a text
> shape?

odt-loading means here just loading of a odt-file with KWord. Atm KWord is the 
only one that really is able to do so since the text-shape misses all the 
logic related to frames and since that logic is essential. So, a text-shape 
is only able to load e.g. the body and/or implement own logic how to put 
different text-shapes on the canvas (what frames are for in KWord).

> For kword it is possible to subclass the ShapeLoadingContext and 
> pass it around, but only kword related classes can use it. I use something
> like that in kopageapp to load the pages which are not handled in flake.

and that's exactly what the loadercontext does except that it allows also 
others to _optional_ use it. Though I wonder a bit now that kopageapp does 
the same but kotext should not :-/

> > > 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...
>
> That is a problem as this will give different text shape a different style
> manger, but all text shapes should use the same style manager. I much more
> think if a application does not provide a KoStyleManager the whole should
> still work and there should be no need to generate one at all.

Right, same problem like before; KoStyleManager need to be passed around 
somehow and if we like to have loading across different text-shapes working 
as well, then we also need to pass the textloader around.

> > >> 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...
>
> Which loadOdf are you referring to? All flake related loadOdf expect to
> have a bool loadOdf( const KoXmlElement & element, KoShapeLoadingContext
> &context ). And it is needed to use this context to pass it on to other
> shapes that are embedded in the text shape.

but still the KoShapeLoadingContext is not enough for odt-loading...

> Have a Merry Christmas,

same, same and beware of 
http://www.bloggerheads.com/images/satan_claus.jpg :-)

> Thorsten
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel


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