[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-15 11:37:18
Message-ID: 200604151337.20250.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 15 April 2006 12:57, Thorsten Zachmann wrote:
> > 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. 

I never even thought of that notion; I was more thinking about people 
moving flake objects around, including moving them between pages.
But yes, in your example it will work just fine as well.

> For kpresenter you have a list of objects that belong to a page, I
> think the same counts for kivio and karbon. 

Well, you can still move flake objects between 'pages', right?

> Therefore I think it is 
> still a good idea to use one object manager per view.

Having an object manager per view was never a discussion point, so I guess 
you mean per page. :)

I think you will come to realize that the solution I described (and used 
before) will end up being simpler (compacter) and take up less memory 
then yours.  I'm not sure why you feel that creating both your solution 
(which, again, will take more memory) as well as the solution KWord needs 
is a good idea. Its simply inventing the same thing twice :(

> > 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. 

It is.
You will end up moving flake objects from one manager to another in case 
of user interaction moving objects from one page to another. Thats code 
you need to write in your solution, not mine.
You will have code to search first for the manager and then for the object 
in that manager. Same for insert, same for painting.
This code will be in _all_ the places that interact with the manager and 
you have simple code-duplication and hence, more code.

Not to mention that its harder to unit-test.

> 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.

Now, thats simply a straw man...
Having a shared class with more functionality then you need is no reason 
to have two implementations of the same idea, one with a little more 
functionality. But most code for that functionality being duplicated.

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