simon-git: xcopy (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  82a11a8 drop mode: call find_real_clientwin() outside enter_receiver().
  29dfc4c drop mode: check XdndStatus is from the current receiver.
  9a8c2c3 drop mode: remove the drop_transfer_ready mechanism.
  4130f1e drop mode: don't deluge receiver with un-acked XdndPosition.
  39eeb6f drop mode: reset last_xdndstatus_was_positive for new receiver.

Repository:     https://git.tartarus.org/simon/xcopy.git
On the web:     https://git.tartarus.org/?p=simon/xcopy.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-01-31 19:41:49

commit 82a11a82bb33f6779d1e13a39aca54eb62ea713d
web diff https://git.tartarus.org/?p=simon/xcopy.git;a=commitdiff;h=82a11a82bb33f6779d1e13a39aca54eb62ea713d;hp=d51117d954d8d3b68f77fd23619bff517704ae37
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Jan 31 19:18:50 2018 +0000

    drop mode: call find_real_clientwin() outside enter_receiver().
    
    This means that the real client window that we interact with, rather
    than the thing we initially identified as under the mouse, is used
    consistently everywhere - in particular, that's now the window
    assigned into 'drop_receiver' and used to check that received messages
    are from the right place and not left over from a previous
    interaction. I've been having trouble with xcopy --drop for a while,
    and I think this mis-setting of drop_receiver and consequent mis-
    addressing of outgoing Xdnd messages has had a lot to do with it.

 xcopy.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

commit 29dfc4c5417f0b11d4780eb08381a3e12b0c4dc6
web diff https://git.tartarus.org/?p=simon/xcopy.git;a=commitdiff;h=29dfc4c5417f0b11d4780eb08381a3e12b0c4dc6;hp=82a11a82bb33f6779d1e13a39aca54eb62ea713d
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Jan 31 19:21:09 2018 +0000

    drop mode: check XdndStatus is from the current receiver.
    
    Now we're getting the current receiver _right_, this should improve
    robustness by ensuring we don't accidentally believe some outdated
    XdndStatus that arrives belatedly from the last window the mouse went
    over.

 xcopy.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

commit 9a8c2c357d501d026da485bcf462c669c4405d10
web diff https://git.tartarus.org/?p=simon/xcopy.git;a=commitdiff;h=9a8c2c357d501d026da485bcf462c669c4405d10;hp=29dfc4c5417f0b11d4780eb08381a3e12b0c4dc6
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Jan 31 19:23:42 2018 +0000

    drop mode: remove the drop_transfer_ready mechanism.
    
    This reverts commit 0b986051a and its followup a320e867a.
    
    Examining other working Xdnd clients shows that they seem perfectly
    willing to transfer the same selection contents more than once, and
    they still don't have trouble with premature or multiple drop events.
    
    So either Firefox (which is what I had the problem with in 2016) has
    fixed some aspect of its own behaviour since then, or - I suspect more
    likely - I misidentified my problem because other bugs were
    confounding my observations, such as the really quite fundamental one
    I've just fixed in commit 82a11a82b.
    
    Certainly, now that I've got those other fixes, backing out the entire
    mechanism doesn't seem to have reintroduced the problem. So I think it
    was misguided from start to finish, and should be thrown away.

 xcopy.c | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

commit 4130f1e0e1cb047161827f3ec7f4c7a57810302b
web diff https://git.tartarus.org/?p=simon/xcopy.git;a=commitdiff;h=4130f1e0e1cb047161827f3ec7f4c7a57810302b;hp=9a8c2c357d501d026da485bcf462c669c4405d10
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Jan 31 19:28:54 2018 +0000

    drop mode: don't deluge receiver with un-acked XdndPosition.
    
    It's never quite _explicitly_ said in the Xdnd spec, as far as I could
    see, but there are definite hints that after you send XdndPosition you
    should wait for an acknowledging XdndStatus before you bother sending
    any further position messages. This avoids flooding the client with a
    pixel-by-pixel account of the exact mouse trajectory which it can't do
    anything useful with anyway.

 xcopy.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

commit 39eeb6f455e2a66ef2bf57a34340a1d6652cfddb
web diff https://git.tartarus.org/?p=simon/xcopy.git;a=commitdiff;h=39eeb6f455e2a66ef2bf57a34340a1d6652cfddb;hp=4130f1e0e1cb047161827f3ec7f4c7a57810302b
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Jan 31 19:30:16 2018 +0000

    drop mode: reset last_xdndstatus_was_positive for new receiver.
    
    When I initialised the new variable 'waiting_for_xdndstatus' to False
    in enter_receiver() in the previous commit, I couldn't help noticing
    that I seemed to have forgotten to do the same for the existing
    variable that tells us whether we currently have a viable drop ready
    to commit. So I now reset that to False too when we have a new
    receiver, on the basis that if we haven't seen any XdndStatus at all
    then we certainly haven't seen one signalling complete readiness to
    accept a drop.

 xcopy.c | 1 +
 1 file changed, 1 insertion(+)