>I think it might be possible for some system dialogs for >high-priority tasks to wait for the dialog to be answered before >allowing the VNC server (or the patches) to continue. I seem to >remember something like this, but I'm not sure. It should be rare, >so it would indeed be interesting to hear about the context.
Indeed! I can't imagine even a high priority alert not using these very basic Mac toolbox calls (Button, StillDown, GetMouse) that are intercepted by the patches. Having said that, the Drag Manager obviously does not use these, but somehow waits for the cursor to move, or the button status to change, before continuing. (I assume that's why the standard vncPatches fails under this situation -because the Drag Manager uses a different way of checking for these things.) I guess if the Drag Manager knows of such a different way, it's possible that other parts of the system might... >I've used ChromiVNC for some years and it is invaluable to me. That's clever! It's only just 15 months old! (Well, it was called TridiaVNC for 3 months before that... :-) >The biggest problem I have found is that it does not honour the RFB >FramebufferUpdateRequest the way the AT&T version does. As a result, >a slow server host can get bogged down sending updates of unneeded >parts of the display. I remember Jonathan mentioning to me that he thought it was better for the client to have the whole display at its end, even if it was not all needed, so it was ready for the case when it scrolled into view (or something like that...) Maybe that thought needs reviewing (some sort of option, perhaps?) Do you regularly view just a particular part of the screen? Bye! Adrian --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
