fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fenfire-dev] Re: back tomorrow


From: Benja Fallenstein
Subject: [Fenfire-dev] Re: back tomorrow
Date: Tue, 22 Feb 2005 01:17:38 +0100

Hei!

On Mon, 21 Feb 2005 11:35:01 +0200 (EET), Matti Katila
<address@hidden> wrote:
> Ok. I think we need to think how the current system works (Cursors for
> being exact) before we can add more spatial canvases, e.g., sprial view.

You mean add more spatial *views* :)

> CanvasSpatialView is tricky. We can use same lob for canvas' content
> everywhere but not for it's panzoomlob coordinates since the same canvas
> can be shown in different places but have different panning because of
> different x,y in structure/connection points.

True. It seems right to cache the canvas content lob separately. (Done
now, btw.)

I think as discussed on IRC, we should have separate methods in View:

    Lob getMainLob(Model cursor);
    Lob getNodeLob(Object node);

Besides it being stupid to have to create a new ObjectModel(new
Cursor.SimpleCursor(n)) for every node n in StructureView :-), this
allows us in StructureView to cache the panzoom stuff in the node lobs
but not the main lobs.

Although currently we rely on caching of the main lobs in an ugly way.
:-( If the mainview lob is re-generated during a drag (because
LobMain.mouse() called animate()), then a new DragController is
created which has 'hasDragging == false'... Don't know how to solve
that well. (Currently it works because the panzoomlob and
dragcontroller etc. is cached, which isn't the right way to fix this
=-))

> I added CancasCursor to Cursor and it has Object canvas,
> focusedNodeOnCanvas; (or something like this). and Model panX,panY,zoom;

As discussed on IRC, I've changed the Models to floats because Cursor
objects are supposed to be immutable.

I've also moved CanvasCursor out of org.fenfire.Cursor into the
org.fenfire.view package; it's not right to put all sorts of special
Cursor classes inside Cursor... FentwineCursor isn't there, for
example.

Which reminds me... I've now made cursors work the way we planned it
when starting work on the demo, but we have to think about it more.
Currently we *either* store an x/y position on a canvas, *or* a
Fentwine rotation. We really want to have both -- dragging the canvas
shouldn't change the rotation, and rotating shouldn't reset the canvas
to have the focused node in the center. This is what happens
currently, and it feels weird and stupid.

The thing is that when designing this, I was thinking we would have
separate Fentwine and Canvas views -- now we have them integrated at
the code level the way they are conceptually, which is great!!! -- ;-)
-- and so the design has to change.

I think perhaps we should have a hierarchy of cursors, so that when an
upper-level cursor changes, the lower-level cursor is discarded, but
when a lower-level cursor changes, the upper-level cursor isn't
affected. Like this:

level 1 -- fentwine cursor
level 2 -- canvasview cursor
level 3 -- text cursor

*scratches head*

Need to think a little more, but we should get something implemented
soon (like tomorrow :)). Ideas?

> For content we can use caching, i.e.,
> 
>     Lob canvas2contentLob(Object canvas);
> 
> But for different panning and etc. we need also CanvasCursor to do the
> caching. For example:
> 
>     Lob contentLob2panZoomedViewPortLob(Lob content, Cursor canvasCursor);
> 
> And this is the tricky phase because of we need to have the cursor ready
> but currently we use only simple cursor.

Sorry, I'm not fully following here, but would the scheme proposed
above address this? I.e.,

    Map canvasContentCache;
    Map nodeLobCache;

    Lob getMainLob(Model cursor) {
        canvasContent = (Lob)canvasContentCache.get(getCanvas(cursor));
        if(canvasContent == null) makeCanvasContent;
        Lob l = new PanzoomLob(canvasContent);
        return l; // don't cache
    }

    Lob getNodeLob(Object node) {
        if(nodeLobCache.containsKey(node)) return (Lob)nodeLobCache.get(node);

        canvasContent = (Lob)canvasContentCache.get(getCanvas(node));
        if(canvasContent == null) makeCanvasContent;
        Lob l = new PanzoomLob(canvasContent);
        nodeLobCache.put(node, l); // do cache
        return l;
    }

> This is important because I would like all views in the Fenfire to be at
> least zoomable.

Explain? :-)

- Benja




reply via email to

[Prev in Thread] Current Thread [Next in Thread]