From: Patrick Lam (email@example.com)
Date: Sat Aug 03 2002 - 11:28:34 EDT
On Sat, Aug 03, 2002 at 10:52:42AM +0200, Mike Nordell wrote:
> Patrick Lam wrote:
> > The fv_Cursor class should also have a thread
> > with a timer; its only purpose in life is to set the boolean every 500ms.
> For X this might be fine, but for Win32 I still think we should change the
> code to use the system provided caret (that takes care of blinking the
> cursor, making sure there is only one instance of it on the desktop and so
> on). I'd go even further to say that this is such a good way of handling it
> that the other implementations should at least consider this design. This
> also suggests that the cursor class shouldn't be fully implemented in XP
> This would bring a couple of good things for all platforms:
> For Win32 it would mean that any cursor implementation bugs on the other
> platforms don't reach Win32. The Win32 code would also be smaller.
> For the other platforms it would mean that they get an design that is tried
> and proven (there just aren't any of these problems on Windows), and if the
> windowing system they use happens to provide a cursor/caret service they
> could make use of that instead of reinventing the wheel yet another time.
If we want to use the Windows caret, we need to make sure that it can
e.g. handle all the funky things that happen for the bidi cursor. But
the cursor is only bad right now because it's not implemented in any
smart way. Once we have it implemented in a smart way, it would be
fine on all platforms. (Calling _eraseInsertionPoint explicitly
really does suck.)
The Win32 code would not be smaller in any meaningful way; we could
save at most 2k from the binary size or
something like that.
A system cursor would be great for MacOS X, where I couldn't
make the cursor blink properly at all (yet).
I know that GTK doesn't have support for such a thing.
p.s. I'm not saying that fv_Cursor is a bad thing to do, but I'm in favour
of solving one problem at a time. fv_Caret is a single thing which can
be fixed by itself.
This archive was generated by hypermail 2.1.4 : Sat Aug 03 2002 - 11:35:56 EDT