Subject: Cursor as its own entity
From: Mike Nordell (tamlin@algonet.se)
Date: Wed May 17 2000 - 10:44:19 CDT
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.
This archive was generated by hypermail 2b25 : Wed May 17 2000 - 09:43:06 CDT