Proxima Home
Gallery
Download
Documentation
   Proxima Client
   Proxima Server
   Proxima Engine
   Building an editor
   User manual
Publications
Contribute
Bug reporting
Oblomov Systems
Old Todos

Proxima
[[http://www.oblomov.biz][test]]
---+++ Taken from !HeliumEditor/DocTypes

1^3 shows that we do want to parse columns. If a digit is inserted before the 1 a parse error occurs, whereas
it should be added before the 1. However, maybe this can be fixed by editing the string inside the column rather
than add before it.

Keeping original mappings at Layout level is hard. Maybe new ones will be generated every edit op.

---+++ Taken from !HeliumEditor/Evaluator


Focus:

Focus is not completely right yet. Instead of passing the focus from gest int. to presenter for every edit, all levels
should keep a focus. This will allow the nice up/down navigation.

Also, a skip doc, operation will reinstall the old pres focus, which is not right if an up down has been performed on
arrangement focus. There is a choice here. Either every level has correct focus, or a skip does lead to a focus update
on the lower level. In the last case, the focus moves up and down only when required. This might lead to some difficult
administration though.

Probably everything will be ok, once we have Level types on all levels, then the passed datastructure will always contain
the current focus, and it is passed only when the lower level cannot handel it.

When we stay at lower levels, the focus will not be correct at the higher levels, this is similar edit ops that are 
short cut at lower levels. Maybe we need a distinction though. An edit on the pres tree without a reparse should signal
that the document is not consistent with the presentation yet, but if only the focus has changed, we don't want that signal.

The difference we have here might be that the focus updates are LS updates.

For now, we fix it by having edit ops that do a skip doc, also set the presentation focus.


edit, compute focus after edit, compute focus in terms of position in string repr.

present: recomputes focus in updated tree from string position except for skip, because then focus is ok.

arrange: translate focusP to focusA

structural problem: if presentation before focus changes in size, the focus is incorrect.
-- this will be solved by having a document focus.


focus on presentation requires rearrange after each focus move. This does not seem to be what we want
will we allow the presentation to be influenced by the focus? This will be even more expensive

mouse handling stuff seems to call for a backtrack in edit levels, try highest level, if fail try lower.
This is not part of the model yet



BUG copy depends on direction!!



-- Main.MartijnSchrage - 12 Mar 2008