fenfire-dev
[Top][All Lists]
Advanced

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

[Fenfire-dev] What happen? Off the top of my head


From: Benja Fallenstein
Subject: [Fenfire-dev] What happen? Off the top of my head
Date: Fri, 4 Feb 2005 18:59:47 +0200

Hi,

this is just an overview of a couple of things that I'm thinking about
at the moment or that I feel need to be done right now.

I really really want to get "something" to work. I haven't done much
for over a month, and I want to get back to being productive.

Um, I've been coding a bit on this new view thing. I've discussed this
with Matti and Janne in person, and it took a long time, but let me
try to give a quick overview. There are basically two ideas that we've
had working independently but not together: a) having changeable views
like in GZigZag and b) having views depending on the position in the
structure (an appointment is shown in a calendar, from there we move
to a person which is shown in a Fentwine view, and from there we move
to an image which is on a canvas).

We want the two together, so that we can change the view used to show
different kinds of items, e.g. the view used for e-mails and the view
used for appointments. But the problem is that these "types" can
overlap; an appointment that has been placed on a canvas is both "an
appointment" and "a thing-on-a-canvas," and it's not clear whether we
should use the current "appointment view" or the current
"thing-on-a-canvas view" for it.

So I've came up with a system together with Janne that we can try out,
in which we have an ordered list of the form

type 1 (appointment) --> view A (calendar)
type 2 (person) --> view B (Fentwine)
type 3 (thing-on-canvas) --> view C (canvas)
anything else --> view B (Fentwine)

Now, we use the first matching rule, e.g. if we have an appointment
that's also a thing-on-a-canvas, the first rule is the first matching
one, so we use view A (the calendar view).

We'll show "calendar view" somewhere on the screen and the user can
change it, perhaps by clicking on it and selecting another view.
(Currently it's done through a keyboard command.)

Now let's say the user says "change the view to canvas view". What we
do then is we look for the first type in the list that both is a type
of the current item and a type that can be shown by the chosen view.
(The user can only select views that can show the current item.) In
this case the first (and only) such type would be type 3,
thing-on-canvas.

We then remove the rule for that type and insert a new rule at the first line:

type 3 (thing-on-canvas) --> view C (canvas)
type 1 (appointment) --> view A (calendar)
type 2 (person) --> view B (Fentwine)
anything else --> view B (Fentwine)

The view for type 3 is the same as before, because the user selected
the one that was already selected for type 3. But the type is on the
top, so anything that is on a canvas will now be shown in a canvas
view.

That's not all we discussed, but all that's implemented so far ;-)
(showing the current view isn't implemented yet).

For the demo to be any nice, we need to make interpolation between
Fentwine and other views work. The demo uses Fenfiction for the other
views. I'm not sure why it doesn't interpolate currently, but we need
to make it interpolate.

Other things to think about:

- Cursor positions -- these must be more complex than just "current
item." For example on a canvas we must store the x/y position. But we
also must be able to convert between different kinds of cursor
positions, so that we can change from a canvas cursor posn to a
Fentwine cursor position which has a current node and a rotation...
- How to implement view controls -- views need settings like which
properties to show in a Fentwine view -- how do we present these to
the user?

Oh, I don't know, there were a couple more things but I need to go now...
- Benja




reply via email to

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