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

List:       koffice-devel
Subject:    Re: floating frames (in kword)
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-10-21 11:28:05
[Download RAW message or body]

On Dimanche 21 Octobre 2001 13:03, Thomas Zander wrote:
> > > More frames for multiple pages. Right?
> > 
> > Well........... that's the bit that isn't really well implemented yet.
> > But that's the plan indeed. Hence the frame number in the above stuff.
> > But what isn't done yet, is the management of those frames
> > (creating/deleting/moving to undo-redo etc.)
> 
> I also miss how to add a KWAnchor to the original text flow when I notice my 
> table will not fit, and needs an additional page. (Well, an extra anchor in a 
> new frame of the hosting textframeset)
No need for a new frame, just a new anchor in the hosting textframeset.
Have a look at KWTextFrameSetEdit::insertFloatingFrameSet().
I suggest something like

CustomItemsMap customItemsMap;
// create the anchor in "anchor"
customItemsMap.insert( 0, anchor );
textFrameSet()->textObject()->insert( cursor, currentFormat, KoTextObject::customItemChar(),
                           false, false, i18n("new anchor"), customItemsMap );

This assumes that cursor (and currentFormat) point to the previous anchor
in the text - which should be quite easy, I guess you know what's the previous anchor.

> I assume I can just store the last parag (provided via the createAnchors() method)
> and in some way I don't see at the moment I can insert a paragraph after this 
> last parag to contain the new cells on the next page.
> Ideas ?

No, don't store paragraphs, and don't create paragraphs either.
Two custom items, big enough, that are one after the other in the same "paragraph"
(as far as QTRT is concerned), will end up one under the other anyway.
So I would suggest: don't both with creating/deleting paragraphs, simply
create/delete anchors in the same paragraph, and since the anchor are (for tables)
as wide as the page, they'll be under each other anyway.
Another solution (if an anchor isn't as wide as the page, but you still want anchors
to be under each other), is to use the "ownline" bool for customitems (it's the first
"false" in the call above).

> Well, any requests to the KWAnchor seems to just call my internal methods, so no
> double houskeeping, luckily :)
Yes.

> Undo/redo is for later, the things that I start facing now are horrible enough :))
As you can see above, you can't dissocate undo/redo from the rest. All the kotextobject
methods take care of undo/redo already (and the i18n call in the sample code above
is the name of the undo/redo command). It's just too painful to set things up in a
certain way first and then re-engineer everything for undo/redo. The kotextobject
API ensures that everything is done the right way from the very first time....

> ps. we do support embedded objects in other framesets then frameset 0, right?
Certainly. m_textFs can be any text frameset.
(As you mentionned earlier, the only place where we only look at frameset 0 is when
making a non-inline frame, inline. In that case we should look at the closer text frameset
(taking into account the implicit z-order etc.), but we currently only look at frameset 0 IIRC).

> is it a bug or a feature that the KWAnchor::move(int x, int y) uses integers and 
> not doubles...

It's a feature, everything in QTRT is in integers - but we now use that as "layout units".
As explained in DESIGN, that's the high-resolution coordinate system (~ 1440 DPI)
that we make QTRT use internally, so that the text layout doesn't depend on the zoom
nor resolution (->WYSIWYG).
So it's like.... very small pixels, so they are in integers.

> KWAnchor::size() for example also returns integer values, but that is a zoomed 
> value, so that seems logical.

No, that one is in layout units too.
KWord is complex... you have to add a new coordinate system to your mind :)
We have unzoomed (double, in points), zoomed (int, in pixels), and layout units (int, in
layout units).

David.
_______________________________________________
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]