[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-15 10:57:40
Message-ID: 200604151257.40824.t.zachmann () zagge ! de
[Download RAW message or body]

On Saturday 15 April 2006 10:51, Thomas Zander wrote:
> In KWord I decided upon the following;
>
> I have a class KWFrameViewManager which is per view and contains all
> frames there are. (in the form of KWFrameView instances).
> This manager has some slots to make sure it gets notified if a frame is
> moved.  The result of this is that it is able to have a cache internally
> based on the Y coordinate of the frame.  This does not exactly have to be
> per page since that will take too much memory.

Ok that shows that kword is different than most of the other koffice apps as 
it can be a continues connection in frames. Kpresenter, Kivio and Karbon 
however only have the objects which are on a page. The objects belong to this 
page and don't change when something on the page before is deleted in to 
kword. If kword needs some more in that case it should be handled in kword. 
No need to put this also on the load of the other applications.

For kpresenter you have a list of objects that belong to a page, I think the 
same counts for kivio and karbon. Therefore I think it is still a good idea 
to use one object manager per view.

Maybe a subclass of an object manager to fullfill the needs of kword is also a 
good idea.

> In another project I just build a tree with a predefined depth of 2 and a
> predefined leaf-count of 1000. Worked very fast :)  But thats
> implementation details...
> So, if flake objects, like frames, have a Y coordinate then building an
> internal cache to make lookup fast I feel that you get the advantage of
> having one object which means less code to manage the objects as well as
> the speed you notice might be a problem if you get many objects.

I'm not so sure it is less code. We need to have all that is needed for e.g. 
in kword to also have for the other applications where it might not be 
needed.

> In other words; I agree with Boudewijn here since you end up creating and
> managing the object-manager.  And you will agree that having a manager to
> manage the object-managers seems a bit silly :)
>
> On Saturday 15 April 2006 05:21, Thorsten Zachmann wrote:
> > I have a different point of view what the object manager should be. For
> > me you have an object manager per view and it has a reference to all
> > objects of the page/sheet. I don't think it is good to have all objects
> > in one big object. It will make the handling very complicated and time
> > consuming if you have a lot of objects. If we have have an object
> > manager per view then one selection per object manager will is ok. This
> > was however I intended it to be when I designed it.
> > I can see now that this might be not what is in need for kword. So how
> > is this handled at the moment in kword or how should it be for kword?
> >
> > Any ideas before everybody starts to implement in a different
> > direction.

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]