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

List:       koffice
Subject:    Re: What kind of HTML is KWord supposed to be able to import?
From:       Thomas Zander <zander () planescape ! com>
Date:       2002-06-13 8:00:10
[Download RAW message or body]

On Wed, Jun 12, 2002 at 01:52:37PM +0200, David Faure wrote:
> On Friday 07 June 2002 11:18, Thomas Zander wrote:
> > On Thu, Jun 06, 2002 at 09:13:45PM +0200, Frank Dekervel wrote:
> > > Op Thursday 06 June 2002 21:07, schreef Frank Dekervel:
> > > > kword's kwanchor::draw doesn't know about multi-page inline frames yet, so
> > > > drawing goes completely wrong. but thats not the only buggy place, there
> > > > must be others (i think but i'm not sure at all in drawing of
> > > > kwtextframeset)
> > > 
> > > sorry. the last one is wrong. its only kwanchor::draw i found to be wrong.
> > 
> > IIRC that code does not even have to be changed (much). The idea was to create
> > a new anchor for the second page.
> > 
> > So a multipage table has multiple anchors. One per page.
> > The hooks are there, but they are not done at all.
> >     QRect KWTableFrameSet::floatingFrameRect( int frameNum )
> > should use the the framenumber to return the page-specific QRect.
> 
> Yes that was my initial idea, but Frank's later fixes proved to me
> that it's much easier to have one big inline frame (char) over two (or more)
> frames, than requiring that the inline framesets handle the "cutting" between frames.
> 
> Ah but then the cutting is done at the pixel level, which isn't what you want
> for tables. I start to see the problem ;)

Yes, and for any text frame.

IMO its not that hard; you just move the intelligence somewhere else. And as with
all things, a concentration of logic you have to debug becomes quite hard.
In both cases the frameset has frames that are put on different pages. An inline
text frame that is split accross pages suddenly has 2 text frames. The funny thing
is that that is nothing new. We just want to avoid copying it in the appendpage
(IIRC we don't copy them since the are inline frames anyway) and now we have 
two frames where the second is created when the first is full.

I really do think your initial design is good, it takes care of things in a way
that fits with the rest of KWord.

Maybe your response of 'this is hard to do' is brought on by the problem of 
debugging 4 parts of the program that interact with each other by using the
cause and effect. I.e. you press something in the GUI, the data structure changes
and the GUI shows the effect.  How to find out if the data structure is changed
correctly, or you have a bug in the displaying code. etc.

My solution has always been to create a little application that initializes the
dataset in a pre-defined way and then emulates the way KWord uses the API (of
our componenet) that triggers the events we are coding.
The test application will then test the outcome of the dataset it holds.
Any errors; you are notified and the test-application exits.

Anyway, testing rulez, and this is just a good start to do that :)

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

[Attachment #3 (application/pgp-signature)]
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice

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