Battle of the cursor over
I’ve spent the last 3 days or so battling an issue with getting the cursor position correct on the screen
when the user is editing a textarea that is within a scrollpane. The insertion point in the textare was fine but the cursor display which is handled by the application at a higher level was going out of synch when the user scrolls the pane.
All it took was a couple lines of code, a couple extra variables so the textarea knows its been scrolled vertically or horizontally, but it took 3 painful days to figure that out. Still not perfect but at least the cursor and insertion point are always in synch, even if the app continues to show the cursor outside the scrollpane when the insertion point gets hidden due to scrolling (hehe). I guess that will get taken care of by the time i’ve got all the widgets upgraded.
Now I am back to the opinion that GUI’s really don’t have a cursor, although widgets know how to appear highlighted when focus falls on them. Textareas and textfields *do* however have an insertion point (perhaps caret is the correct term). Thus, the widget (rather than the app) should maintain and display a caret. This will take care of issues like making the caret invisible if the insertion point is overlapped or scrolled off, or moving it around.
# Overheard on the net
Also, Python strives for readability. I feel the existence and popularity of Ruby has been a net positive for Python, because it keeps programmers who don't greatly value readability away from our Python codebases.
— Python, Ruby, Power