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

List:       koffice-devel
Subject:    Re: Flake design
From:       Thomas Zander <zander () kde ! org>
Date:       2006-04-17 18:44:41
Message-ID: 200604172044.41962.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 17 April 2006 19:30, Thorsten Zachmann wrote:
> The object manager I think of does not do much. It holds a reference to
> a list of objects. This can be a list of objects of the current page in
> case of kpresenter or karbon , in case of kword a list of all objects
> in the hole document. The object manager is than used by the tools to
> give them the right objects and keeps the selection.

First off (to eliminate confusion) we fully agree that there the object 
manager should be per view.
Your suggestion above is something I did understand, yes. Thanks for the 
explanation though :)
Thing is, if you have an object manager for the current page, that will 
mean you have 10 object managers for 10 pages and 20 object manager if 
that same 10 page doc has 2 views.
Without talking about on memory usage, that will mean you need to manage 
the object managers.  Something that you will have to reprogram in each 
application working like that.
I'd like very much to avoid that, don't you?

> > Well, you can still move flake objects between 'pages', right?
>
> I have no problem with moving objects between pages, but in kword this
> might be done differently than in kpresenter. I also don't think that
> flake should know anythink about a page.

Thats funny; since in your explanation above I got the distinct impression 
that flake would have to know about, ehm, a section of the document. So, 
how do you propose we manage the objects not in the current page?

> > Having an object manager per view was never a discussion point, so I
> > guess you mean per page. :)
>
> Quote form my first mail:
[snip]
I never disagreed on using an object manager per view; I just disagree 
that you need more then one object manager per view.

> For kpresenter e.g. I have the the need to be able to
> animate the objects. Therefore I like to have need to have all objects
> of one page.
Which is quite easily done with proposal of one object manager (per view) 
which holds all the objects. Did you look at the class I referenced?
http://www.englishbreakfastnetwork.org/apidocs/apidox-koffice/kword-apidocs/classKWFrameViewManager.html

Having a method that does not return the view() based on a KoPoint but a 
list based on a KoRect (for a region, like a page) is what you probably 
want for such a thing.

>  But I also think to put this in flake would be a mistake as no other
> application needs this.
Well, I guess I disagree there.
Take a look at QLabel; its in a library and you will hardly use all the 
functionality in your application.  Does that make it bloated and does 
that mean Qt should tell its users that they should subclass it?
Actually, no. It does not get bloated by adding some code while still 
reusing a lot of concepts and ideas.

Same with an objectManager like this; everyone uses the class but not 
everyone uses the same subset of functionality.
The class just stores all objects and certain applications need different 
ways of retrieving the objects. If nothing else, I am sure that all 
applications will benefit from the lookup-cache :)

-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

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