I've now come closer to a working solution. What got me to create this was that the current model, pardon the language, sucked. It's a common design decision to make the view handle all this. I.e. MVC (Model View Controller) becomes Model (e.i. doc) and View (i.e. combined View and Controller). However, in complex projects (which I think we must credit AbiWord to be) it will fit not-so-good. Anyone messing around in FV_View and all that selection, edit, insertion and-so-on code would probably agree. As it is now, the view takes care of everything from cursor movement to erase/insertions and selections. This will (time, permitting) be corrected. What I've come up with is the following: One class FV_Caret, that is to only be used by the other new class FV_Cursor. Caret is the (possibly blinking) visual marker of the insert pos. It takes care of its own timer and so on, and is meant to be a non-brainer to use. I think you'll find its interface self-explanatory. I changed the FV_Views draw/erase insertion point to cursor enable()/disable() (since it takes care of its own timer and so on). On enable() it starts by instantly draw the caret, and then possibly start its "blink" timer. On disable() it stops the timer and (if neccessary) removing the visual caret. FV_Cursor is the one that has an PT_DocPosition (i.e. knows where it is within the document). It's also the one that knows where to put the new doc.pos. on cursor movements (don't worry, it _has_ a setDocPos() method also for e.g. mouse-clicks). I've implemented up/down/left/right/home and end calls. What's remaining is implementations for pageUp, pageDown, wordLeft and wordRight (there _might_ be other keyboard-movement commands I forgot about). It also has a helper class that exposes the acquire/release idiom within its c'tor/d'tor (i.e. c'tor disables cursor, d'tor enables it again. It's suppoed to be used as as stack instance). It still is sub-optimal, since FV_View should (as its name implies) only be a view, but as I wrote: time permitting... REQUEST: The obstacle right now is that I'm getting _REALLY_ tired of this, since I've basically been messing around with the same problem (to know if the caret XORing is _really_ painting it, or if it's erasing it) the last three days. This is fortunately enough now solved (for most of the cases at least, I think). I've done some surgery in FV_View and some lesser changes in fl_BlockLayout that is a friend to FV_View (i.e. touching FV_Views private parts, wierd friendship this is if you ask me...). These classes/this implementation is not yet ready for public consumption (interfaces aren't 100% correct among other things) why I won't send any patches just yet. The code is to my knowledge however 100% XP. But: Is anyone interested in 1) taking a look at what's left to be done with this and 2) possibly also finish the remaining four movement commands? It would also be appreciated if someone with a _thorough_ understanding of the internal workings of e.g. relationships between e.g. FL_DocLayout/fp_Line/fp_Run/fl_BlockLayout and so on would take a look at it and see if I've done any serious performance (or otherwise) not-so-great design mistakes. /Mike - usually "please reply to AbiWord-dev only", but on this occasion you can mail me for code.
