>>2) Double-clicking in the Finder is improved somewhat, but still
>> quite unreliable
>
> I'll try fiddling with some code, and see if I can get it to give some
> extra time back to the system in between mouse button transitions,
> which should help if the Finder really is doing it's own double-click
> handling.
I doubt it very much - the problem is that the Finder, as soon as it
receives a mouse-down event, blocks for the double-click time.
(Actually, there does seem to be a small window while the drag manager
is in WaitMouseMoved - once that returns the Finder blocks, but only if
WaitMouseMoved returns false - i.e. the mouse has not moved.)
Of course, if the second click does not get through until the Finder
has finished its blocking, then it is too late - the double-click time
is over!
I've gone through loads of traps trying to find one that the Finder
might call during its pause (and hence get time for the server).
Since I have not found one (except on my duo, where it appears to
call both Button and TickCount) I suspect it is using low-memory
globals to see if the state of the mouse has changed.
The only way out of this that I can see is to revert back to (a more
reliable) interrupt-time checking for received events (actually,
deferred-task-time, I think, since OTRcv is not interrupt-safe).
To this end, I was wondering if you could once again make the Int_*
routines deferred-task safe, Jonathan, (i.e. use LMGetTicks instead
of TickCount etc., if necessary, and take out the mouse event pause)
and then provide a new hook into the server, like vncSystemTask, but
which only calls Int_ParseRFB...
I will then see if I can set up a Time Manager task, which will
install a deferred task to execute it from vncPatches68k.
(Also, if an extra hook is added like this, it may be worth splitting
Int_ParseRFB out from vncSystemTask, so they can be called separately
by the patches, as and when the patches see fit...)
Just a thought...
>> a few minor oddities with regard to cursor tracking on slower Macs
>
> might be coupled more to System version
Nope - I can produce the same effect on the iMacs (but it's much much
much more difficult to do it!)
> re-entrancy code needs updating so that it cannot attempt to send
> updates to the server during sending of an update.
vncPatches68k does that already - but there is this possibility that
I mentioned of it slipping through the SystemTask patch when the
server executes its own task loop without the patches providing that
time...
The fact that it happens when frontmost would thus be explained,
though it could still conceivably (but much more rarely) happen
when not frontmost. Since it's not that easy to do even in front,
it would be extremely difficult when not in front!
>I put in the overwriting-low-memory patch you suggested, so it is no
>longer needed in your patches.
yes and no - it does basically work OK without me doing anything in
the patches, but I was trying to regain an extra functionality that I
had in the patches which allowed command-key modifiers that also had
either the option key or the ctrl key (for example, Make Alias uses
a command-option drag, or the control-strip default hot-key is
ctrl-command-s).
I had vncPatches68k set up to emulate these by substituting the shift
key for the command key...
Anyway - enough typing for tonight!!
Goodnight!
Adrian
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
