[interfacekit] Re: server part of BDirectWindow

$ lurkmode --off

I've been following this thread all day and have been doing some 
serious thinking about what Rudolf has said. Dealing with 
BDirectWindows has been something I didn't even think of (or even 
realize was necessary to deal with). I can think of a couple 
possibilities - (1) doing some sort of solution which supports color 
whenever possible and appropriate or (2) pushing off until R2. Software 
cursors aren't set in stone, but they're a feature I *really* want to 
have in R1 as long as it's not totally stupid to do so. BTW, flicker 
hasn't been a problem yet. :)

#1 would be my preference as long as it is done well. The only thing I 
can think of is something quite similar to Gabe's ideas of dynamic 
software/hardware mode switching. A specific app_server message is sent 
(currently a private protocol) to make a cursor out of a BBitmap, so 
figuring out when we're dealing with color isn't too hard. Rudolf's 
problem is the only major one to the whole concept as a whole. 
Unfortunately, it's a big one, and the only solution I can think of for 
R1 is using a hardware cursor (of some sort) whenever the pointer is 
over a BDirectWindow's client area (or when there is a BWindowScreen 
connected) and switching back when the pointer leaves the client area. 
My question concerning the idea is whether or not it would be confusing
/goofy/nonsensical to do so. Thoughts on this? OTOH, if we must wait 
until R2, some not-very-involved changes will need to be made to a 
couple of classes to make everything work right.

On a better note (Eb, I think), my cubital tunnel syndrome (*not* 
carpal tunnel syndrome as I'd been originally told) difficulties are 
slowly (and if I'm *very* careful about time at the computer, surely) 
making headway. It is no longer a question of whether I come back, but 
when, and when I do, I'll be the first one to cheer. :) Better get off 
now - don't want to push my luck. TTFN

--DW

$ lurkmode --on

Other related posts: