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

List:       koffice-devel
Subject:    Re: playground/office/flake
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2006-04-24 14:44:11
Message-ID: 200604241644.11500.t.zachmann () zagge ! de
[Download RAW message or body]

Hello,

On Monday 24 April 2006 10:23, Thomas Zander wrote:
> On Monday 24 April 2006 06:56, Thorsten Zachmann wrote:
> > I know you did not know this as it is not documented properly. Maybe we
> > should disccuss thinks like this before a lot of code gets changed and
> > it has to be changed again.
>
> Now you know why you guys need to document your code. And why I have been
> asking again and again to do so.
> So, _all_ flake programmers, get in there and document your design and
> methods! Please.

You are right about this. 

> > I'm sorry that I have to say that, but I don't think that is what we
> > need. There are good reasons it was as it was before you changed it.
> > Here is how we planned it at the weekend at Boudewijns:
> >
> > The z-order is defined by the order in the linked list.
> > The reason for that is that it is much easier to manage.
> > If you change the order only the object order in the list has to be
> > changed and not each object. Also it is much faster to insert and
> > remove objects from a QLinkedList.
>
> Well, lucky for me then that the design of using the internal store of the
> object manager to store the way a set of objects are displayed just looks
> like optimalizations that totally defy object orientation and, in the
> case KWord actually wants to use this lib, just can't work.
>
> I'm surprised you guys propose to keep an object property inside the
> object manager which even relies not on the API of the object manager,but
> on its implementation. 
See 1.
>
> As you agreed earlier KWord needs a lot more from an object manager as the
> default one we supply, we have to manage hundreds of pages and many times
> that in objects in one object manager.  Using a linked list there just
> does not work for those amounts.
>
> > So please undo this change.
>
> I won't until we found a good object oriented (aka, maintainable and
> extendable) solution that solves the issue not only for some apps, but
> also for KWord.  To have the object property actually on the object
> solves the problem for all possible uses.

Ok lets start with an explanation of what the object manager does. The object 
manager holds all the objects which can be edited at the current moment. For 
kpresenter/kivio/karbon that are the objects that are on the active page. For 
krita that might be the objects in one layer. If you change the page/layer 
the object manager gets updated with the new list of objects.1

For kword we need something different as you can modify objects on more than 
one page at the same time. You still have a list(or something else) for all 
objects. Additional to that list you have some kind of additional lookup e.g. 
hash tables/maps, to get all object on a page, the z-order of the objects on 
each pages and so on.

Also I have no problem if kword uses a totally different approach on storing 
its internal data. The object manager is still a object that manages the 
objects. 
If we than have to abstract the storage of the objects as for kword a list is 
not good, I think that is the way to go. Here are some examples of what the 
storage needs to be able of: add an object to the storage at a defined 
position, remove an object, change its position and so on. Yes this is a bit 
more work as we need to have the functionality in both implementations, but 
it keeps us more flexible in the usage of flake. 

(1.) The object property (z-order) is not keep inside the object manager as 
you write above. The property of the z-order is in the list of objects 
itself. It is just that the object manager gets this list and manages it. In 
case kword uses a different storage for internal use the object manager uses 
this format internally.
In kword the object manager would allways have access to all objects of the 
document. Of if you could have different files which are parts of the same 
document (e.g. one file per chapter) the object manager would get an update 
if the chapter is changed as when you work in one chapter only objects in 
this chapter can be modified.

I'm not sure that I could explain it detailed enough so if there are questions 
please ask and I try to answer them as good as I can.

Have a nice day, (it is warm and sunny here)

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]