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

List:       koffice-devel
Subject:    Re: kword frames design improvements ?
From:       Thomas Zander <zander () planescape ! com>
Date:       2002-07-04 20:26:12
[Download RAW message or body]

Sorry for slow reply, plus I only skimmed the sources..

On Fri, Jun 28, 2002 at 06:41:54PM +0200, Frank Dekervel wrote:

> 1. problems with current kword frame code:
> -----------------------------------------
> 
> * absolute coordinates
> 
> 	all frames, even inline ones use absolute coordinates now.
Agree. very annoying.

> * no clean frame/frameset separation
> 	
> 	the conceptual 'frame' imo is a rectangle showing a part of a frameset.
> 	the conceptual 'frameset' is the 'document' the frame shows. especially
> 	in the painting code this concept isn't applied consistently, with
> 	methods like kwframeset::drawframe.
> 	also, a table currently is not a frame but a frameset , altough it
> 	has all the properties of a frame.
I believe the concept is correct, but you are right that the implementation
sometimes lacks an undertanding of the concepts.

> * layouting system has to be adapted every time a new feature is added.
Agree.

> * lots of code duplication (eg in painting/selection code)
Agree.


> 2.1 the concepts
> - - - - - - - - -
> 
> i separated the concept of a shape in a document from the concept of a viewport (a \
> 'view' on a frameset). in my test app, the shape is called 'Child', and the \
> viewport 'Viewport'. The 'frame' class inherits both classes. The reason for the \
> separation is code reuse: a page is also a viewport (see later). 
> Maybe it would be better to use aggregation instead of inheritance for \
> frame/viewport relation.
I love multiple-inharitance :)


> Also i didn't implement frames that don't have a parent frameset. So even in DTP \
> mode, each frame would have parent frameset, not necessarily a textframeset \
> (probably i would introduce a main 'document' frameset, each page being a viewport \
> on that frameset)

I don't know what this means.

Each frame in the current solution has a frameset as parent. They have to, the \
frameset contains the content, without a frameset there is no usage for a frame.  \
This is true in DTP mode as well. Or do you mean the frameset 0. The frameset that \
has its frames auto positioned on each page? Then the page being a viewport of that \
'document' frameset is not something I can get my head around, since you want some \
way of positioning headers/footers etc as well, right?


> 2.3 concrete: the painting and the selection code.
> - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> The painting code is located in 4 functions:
...
> frame::drawContents just calls viewport::draw, and frame::draw inherits \
> child::draw.

This looks a lot like how an SVG viewer I have been playing with recently does \
things, using lots of transformations.  The downside is simple; the complexity is \
going up quite a lot for the part that does the transformations.  If you believe that \
can be done correctly then I think the overall benefit is very good.


> 2.4 further ideas
> - - - - - - - - -
> 
> -> keep the table frameset but add a table frame
Hmm, From some viewpoints the current solution is quite nice. There is however an \
added complexity in lots of code that has to do things differently for tables, \
completely outside the tables code I am not happy with.  I'm not sure what you mean \
with this idea though, I'd like to know more about it and how it fixes my problem of \
having to fix stuff outside of the tables class concerning tables every couple of \
months.  

> -> KoPolygon and KoPolygonSet, a bit like QPointArray but for KoPoints,
> with intersection methods. We'll need this (i think) to do run around frame,
> and similar.

I want to point out a feature used in many DTP programs today that make non-rectangle \
frames an obsolete feature request, so you won't go breaking your head on that :) Non \
rectangle clipping. Its not really a problem to have a rectangle frame if the \
runaround and transparancy can be altered using some kind of vector. Think about a \
picture that is transparent and has a non-rectangle edge. It should be possible to \
draw an outline using some kind of polyline which the text will run-around. for \
example; http://www.designer-info.com/p57comp.jpg

> -> editing: we could use top-down painting (to paint the frameset-edit, we
> just paint the uber-parent with the proper cliprect)

Would be quite slow on large documents since we do lots of conversions before being \
able to do a intersec, but optimizations would be possible, a global \
recent-conversions-cache comes to mind :)

> or down-top
> (we paint the frame directly, this is tricky because a frame is not a continuous
> area or rectangle anymore). i think top-down would be the best decision.
Right.


I miss a runaround solution. This finds out if where to start to draw content based \
on the position of other frames.  If nothing else it will be harder to do with the \
current setup since you have to compare 2 different coordinate systems by converting \
to a 3th...


Pondering about the whole; 
the changes you propose mean to replace about 50% of KWords code (not counting the \
koffice/lib stuff).  I think it is worth it, but it will mean a huge amount of time \
and effort will have to be spent on this. If you are prepared, and find others \
prepared to help. I'm all for this change.

Let me re-iterate that there are lots of bugs in tables code concerning frames, and \
things like inline frames/tables are quite buggy as well.  I have no doubt those can \
be fixed, but it appears that we go fixing them a bit to often, which to me means we \
either need a good amount of test cases, or we simply have a problem in object \
design.  The latter will be helped with your work, which looks quite good!

-- 
Thomas Zander                                           zander@planescape.com
                                                 We are what we pretend to be


[Attachment #3 (application/pgp-signature)]
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel

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