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

List:       koffice-devel
Subject:    Re: Page Variable Support
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2009-08-24 18:51:57
Message-ID: 200908242051.57628.t.zachmann () zagge ! de
[Download RAW message or body]

On Sun August 23 2009, Thomas Zander wrote:
> On Sunday 23. August 2009 07.39.49 Thorsten Zachmann wrote:
> > On Sat August 22 2009, Thomas Zander wrote:
> > > On Friday 21. August 2009 22.17.40 Thorsten Zachmann wrote:
> > > > it worked fine this exact way in koffice 1.x and I think it can see
> > > > no problem to behave like that also in flake e.g. by getting the page
> > > > number in the paint method.
> > >
> > > Actually, that would really be a huge problem.
> > > A lot has changed since we used Qt3 and a lot was fundamentally wrong
> > > with doing stuff like that in the paint method, for example we actually
> > > had different looking text at every zoom level. Embedding of shapes was
> > > practically impossible, tables was not really possible to do right etc.
> >
> > I can't see what that has to do with what I proposed.
>
> You suggested to relayout the text in the paint method of the text shape.
>
> This implies this happens for *all* shapes, every time, in all
> applications. Also for page 1 of a 1000 page kword document.
> This implies we can no longer do layout that takes a long time since that
> would make kword really slow. (it would relayout pages 2-999 too on every
> paint)
> Even without that, it means things become impossible; like table layout,
> concepts like anchoring shapes and doing layout 3 times just to get things
> right.

I did not suggest any of the above. The use case you describe is perfectly 
fine for kword. But I don't think that any of that is needed for kpresenter. 
>
> Bottom line; the application should decide to force a relayout of a shape,
> this decision can not happen at the text-shape level.
>
> And this is exactly what I suggested in the bugreport; kopageapp calls some
> method on the kotext api to tell one shape to relayout.

As already noted that does not work in kword at the moment.
>
> You need to use proxyShapes concept though, since the exact same shape
> being shown on two different pages *will* have the exact same content.

Lets see if I can find a solution that makes it work for kpresenter with doing 
all that extra stuff which I think should not be necessary.

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