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

List:       koffice
Subject:    Re: Floating frames - what semantics do people expect?
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-06-01 18:45:55
[Download RAW message or body]

On Thu, 01 Jun 2000, Shaheed Haque wrote:
> I'm making solid progress on flaoting frames, but I have some questions
> about the detailed semantics people would like to see. All comments
> welcome!
>
> Background
> ----------
>
> Each floating frame has an "anchor" which is represented internally as a
> zero-width character, with a special symbol that shows up when
> "view->formatting" is enabled. There are currently no restrictions on where
> in a paragraph an anchor may appear (later, I might want to limit it to the
> end of a paragraph).
>
> Currently, I only support floating frames which are part of a table, but
> extensions to other types of frames should be easy in due course.
>
> Should tables float by default?
> -------------------------------
>
> When a table is created, should the floating mode be selected by default?

Yes. Usually you want to keep things together.

> If the answer to this question is "yes", is it even necessary to support
> fixed-location tables (which is all we have today)?

I wouldn't throw that away. 

> Copy question
> -------------
>
> Currently, copying a range of text is performed both on explicit user
> request (e.g. copy-then-paste), as well as implicitly (e.g. when splitting
> a paragraph). In the implicit case, the copying is usually only done as an
> intermediate step - there will only be one copy of the anchor at the end of
> the operation.
>
> When a range of text including the anchor is copied on explicit user
> request, should the anchor be copied too? Note that if th answer is "yes",
> this implies that the anchored object should be copied too, since we cannot
> have two anchors for the same object (!).

Hm.. difficult issue. For the time being I would consider the anchored object 
to be part of the selection. So copy/cut/paste should work on them as well.
The disadvantage is that you will need to copy the objects. If this turns out 
to be very expensive it might be a solution to let the objects "share" teh 
actual data between each other. (Just like a QString does). Especially for a 
sequence like "copy-paste-delete" that would save a lot of resources.

When you have that in place you might want to add some configurability to it:
When a user deletes text with objects anchored in it, I would ask whether the 
object should be deleted as well. 

> If the answer is "no", I will have to make the internal routines
> distinguish explicit and implicit copies.
>
> Delete question
> ---------------
>
> If the anchor is deleted, should the anchored object be deleted too? That
> would be consistent with how Microsoft Word works. The alternative might be
> to delete the anchor and simply make the table "unanchored", and then allow
> the "reanchor" operation to create an anchor.
>
> Asking the user using a dialog box is probably the wrong thing to do, as it
> would make cut-then-paste of a region with anchors a tedious operation.

You can put up a dialog box for the first object and put a checkbox with 
something like "apply to all objects in selection" in it (on by default).

Cheers,
Waldo

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