[Fenfire-dev] Re: back tomorrow

[Benja Fallenstein]

Re cursors:

On Tue, 22 Feb 2005 09:39:26 +0200 (EET), Matti Katila
<address@hidden> wrote:
> Something similar. I was thinking that since we have structure and spatial
> view divided into own parts should we just have a own cursor for both?
> 
> There are cases, however, when that would not make sense. For example
> assume a canvas spatial view and you have just made into it by browsing
> from left or right. By rotating you can change the rotation of current
> node and the structure it has but if you go away from the node, like
> panning the canvas, what should happen to rotation?
> 
> If rotation should go back to zero (or half?) then we need to create a new
> cursor but if not, we should have different structure cursor for each
> node.

Hmm. So I think we want to at least associate a "current rotation"
with every node on the current canvas. (Well, we can omit actually
storing it for those nodes for which the user hasn't changed the
rotation.)

I.e., let's say the canvas has nodes A, B, C. We enter the canvas by
following a link to node A. The rotation of node A is on the link we
followed to get here. Then we pan the canvas and focus node B. Then we
rotate the connections of B. The rotation of A should stay the same
(on the link we followed to get to A). I think that's the behavior we
"want."

I think it may be ok to forget all the rotations when we follow a link
from B away from the canvas. I'm not sure, but I think we can at least
try it.

So we have to store the rotations of all the nodes shown in the
current spatial context -- i.e., the structure points. This is
essentially the information we need to store for the structure view.
(What we actually store is not a number, but a connection -- i.e.,
property, direction, and connected node.)

For the spatial view, we need to store the spatial position -- e.g.,
in the case of canvases, the canvas, the x/y position, and the focused
node (if any); in the case of calendars (whether in a calendar or a
spiral view), the date/time and the focused node (if any); in the case
of the simple spatial view, just the focused node.

Additionally, we will need to store a text cursor... or other type of
cursor inside the *content*. I think this should be determined by the
*content* view, which we don't have yet...

When the focused node changes, the content cursor is discarded.

When the user traverses a link in the structure view, the spatial
cursor is discarded. Also the rotations are discarded, at least for
now.

When the user moves in the spatial view, the spatial cursor changes.
The focused node may stay the same, though, in which case the content
cursor doesn't change. Also in any case the rotations don't change.

Hmm.

How about

    Model cursor;

    final class Cursor {
        final Object spatialContext;
        final Model spatialPosition; // type of object depends on the
spatial view
        final Map rotations;
        final Model nodeCursor; // contains a NodeCursor
    }

    final class NodeCursor {
        final Object node;
        final Model contentCursor; // type of object depends on content view
    }

So:

- A Cursor object has a *fixed* spatial context, but a *mutable*
spatial position, nodeCursor, and set of rotations.
- When you move in StructureView, it creates a new Cursor and does
'cursor.set(newCursor).'
- When you move in the spatial view, it creates a new position object
and does 'cursor.get().spatialPosition.set(newPosition)'.
- When you click in the spatial view, changing the focused node, it
also does 'cursor.get().nodeCursor.set(new NodeCursor(...))'.
- When you move the text cursor, it creates a new content cursor and
does 'cursor().get().nodeCursor.get().contentCursor.set(newContentCursor)'.
- When something isn't applicable, it's 'null' -- e.g. when a node is
focused but there is no text cursor, then contentCursor.get() == null;
if no node is focused, nodeCursor.get() == null (and thus there can be
no content cursor).

This is designed so that it "naturally" discards all the different
kinds of information at the time where they should be discarded,
according to the criteria earlier in this mail.

Does this sound sensible?

Cheers,
- Benja