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

List:       koffice-devel
Subject:    Re: initializing values in shapes
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-12-26 15:20:37
Message-ID: 200712261620.37662.mail () dipe ! org
[Download RAW message or body]

On Wednesday 26 December 2007, Sebastian Sauer wrote:
> On Tuesday 25 December 2007, Thorsten Zachmann wrote:
> > > > > > Also during copy and paste the data is not yet available.
> > > > >
> > > > > The addShape will be called after the paste; not sure what you mean
> > > > > with 'the data' here, but I can't believe that just having an extra
> > > > > method on the same interface object will help in any way.
> > > >
> > > > yes it will be called after the paste. That means the style manger is
> > > > not there when the shape is loaded.
> > >
> > > The application should create a KoTextLoadingContext, no?  Every
> > > application that chooses to support the KoText library should have an
> > > instance of this class instead of an instance of KoOasisLoadingContext.
> >
> > That is not the way I designed it but can work this way. The way it is
> > designed is that all uses a KoShapeLoadingContext for loading. Somehow
> > the loading of the text does not follow what was designed in flake.
>
> Because the design didn't matched the requirment for loading and for us it
> was easier to change the design (well, imho not really changed but extend
> it) rather then the requirment.
>
> > The way
> > KoTextShapeData::loadOdf is implemented it breaks what is needed to make
> > loading of embedded shapes in a text shape work as the
> > KoShapeLoadingContext is no longer used but only the given
> > KoTextLoadingContext or in case it was not given a new one is created.
>
> KoTextLoadingContext inherits KoShapeLoadingContext, so it extends rather
> then replaces. The funny thing here is btw that afair Jan sayed it works
> fine for him with Karbon :-/
>
> > > That is why the text one inherits from the oasis one. So an application
> > > can choose to instantiate a text one if it links to the KoText library.
> > >
> > > > So the loading will create a new
> > > > stylemanger for loading. And that is wrong as for kpresenter and
> > > > kivio we only need one style manger.
> > >
> > > If this happens in kpresenter, then kopageapp should have created a
> > > KoTextLoadingContext so the stylemanager is available during loading.
> >
> > From what I understand the code the style manager has to be there when
> > loading a text shapes that it can work correctly. The following assumes
> > that that is the case.
> >
> > And here come the problem where addShape does not work
> >
> > If a user copies several shapes and pastes them again all this handled
> > within flake. But as the style manager is not available yet at loading
> > (addShape has not yet been called). So to make the style manager
> > available during a shape is pasted I see the following two solutions:
> >
> > 1. Add an API so that flake can get a KoOasisLoadingContext from the
> > applications to use for loading. If an application supports a style
> > manager it can return a KoTextLoadingContext if not it returns a
> > KoOasisLoadingContext.
> >
> > 2. Use the solution I proposed that will make it possible to set document
> > wide stuff in a shape after it is created. This will also make the
> > KoTextLoadingContext unnecessary.
> >
> > If however the style manager is not needed during loading I propose to
> > remove the KoTextLoadingContext as I can't see the use of it.
>
> 2) sounds fine as in the most logical way to go imho, but if you remove the
> KoTextLoadingContext class, please check that files still load since I
> doubt that 2) makes KoTextLoadingContext unnecessary (and it would be so
> horrible demotivating to see it such deep broken at this state). Anyway,
> any idea/hint/code how to remove it while preserving the functionality
> would be very welcome :)
> Also if there are any questions please just ask since I know that the code
> is rather confusing (but unfortunately I've the feeling it's not easy to
> change that - p.s. the flake-code is imho even more confusing to me :-)

a small extension;
and we would still have the alternate to let KoOasisLoadingContext inherit 
QObject and allow that way to attach own stuff... or at least 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]