--Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > ----------------------------------------- >=20 > * absolute coordinates >=20 > all frames, even inline ones use absolute coordinates now. Agree. very annoying. > * no clean frame/frameset separation > =09 > 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 > - - - - - - - - - >=20 > i separated the concept of a shape in a document from the concept of a vi= ewport (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 vi= ewport (see later). >=20 > Maybe it would be better to use aggregation instead of inheritance for fr= ame/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 introdu= ce 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 positi= oned 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/f= ooters etc as well, right? > 2.3 concrete: the painting and the selection code. > - - - - - - - - - - - - - - - - - - - - - - - - - >=20 > The painting code is located in 4 functions: =2E.. > frame::drawContents just calls viewport::draw, and frame::draw inherits c= hild::draw. This looks a lot like how an SVG viewer I have been playing with recently d= oes things, using lots of transformations. The downside is simple; the com= plexity 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 benefi= t is very good. > 2.4 further ideas > - - - - - - - - - >=20 > -> keep the table frameset but add a table frame Hmm, From some viewpoints the current solution is quite nice. There is howe= ver an added complexity in lots of code that has to do things differently f= or 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 a= nd how it fixes my problem of having to fix stuff outside of the tables cla= ss concerning tables every couple of months. =20 > -> 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 you= r head on that :) Non rectangle clipping. Its not really a problem to have a rectangle frame if the runaround and tra= nsparancy 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 befo= re being able to do a intersec, but optimizations would be possible, a glob= al 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 decisio= n. Right. I miss a runaround solution. This finds out if where to start to draw conte= nt based on the position of other frames. If nothing else it will be harde= r to do with the current setup since you have to compare 2 different coordi= nate systems by converting to a 3th... Pondering about the whole;=20 the changes you propose mean to replace about 50% of KWords code (not count= ing the koffice/lib stuff). I think it is worth it, but it will mean a hug= e amount of time and effort will have to be spent on this. If you are prepa= red, 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 fra= mes, 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 yo= ur work, which looks quite good! --=20 Thomas Zander zander@planescape.c= om We are what we pretend to = be --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0kr2QACgkQCojCW6H2z/TNdwCgvi3+ceBAPoej85H3B/qQMvVt NSIAni7mDvO9jx1FxmitCHSZDWJXqz1E =oRQ2 -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel