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

List:       koffice-devel
Subject:    Re: Flake design
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2006-04-18 14:40:12
Message-ID: 200604181640.12828.t.zachmann () zagge ! de
[Download RAW message or body]

On Tuesday 18 April 2006 09:10, Thomas Zander wrote:
> On Tuesday 18 April 2006 08:21, Thorsten Zachmann wrote:
> > We have only one object manager per view. As Peter allready mentioned
> > is that the object manager gets an update when the page changes.
> > In kpresenter this would be handled like to following. We have a
> > document. The document has pages. Each page has a list of object on the
> > page. So if the page is changed the objects manager will get the new
> > list of objects of that page ( See method void
> > KoObjectManager::setObjects( QLinkedList<KoGraphicBase *> &objects ) ).
> > For other applications this can be different and therefore this should
> > not be done in flake.
>
> I guess that when you say "page" you mean an object that is part of the
> document and not an object that has an instance per view?

Yes, a page is an object that is part of the document and you have each page 
only ones per document. 

> If so, this strategy will get you in trouble for a couple of points;
>
> a) registering flake objects in the page makes the view objects (including
> the selected boolean) per page and not per view, which means that showing
> a new window of the same page will select the same objects in all windows
> at the same time.
> For example in dual-monitor setups (usefull while presenting) where you
> have a editing and a slideshow view at the same time, thats not nice.
> Plus that any caching done in flake objects for zooming becomes impossible
> if you want to allow different zoom levels per view.

This is allready no longer a problem as the selection is no longer stored in 
the object itself.

> b) painting thumbnails of different pages needs to paint the flake objects
> and thus needs to access them.  So if you don't store them in an object
> manager you need to manage them from somewhere else. This means you end
> up with object management methods in your page objects.

That is correct, but the object manager is there for modifying the objects. 
You don't need it just for painting the objects.

> c) printing so called cover sheets where there are 6 kpresenter pages
> printed on one paper-page becomes awkward ;)

It is no problem at all. We do it like this in kpresenter at the moment.

> I'm willing to let this issue be and maybe revisit it when we actually
> have some implementation.

Good idea.

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]