[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28620: Interact directly on Emacs bug#28620: mouse drag event record
From: |
martin rudalics |
Subject: |
bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window |
Date: |
Tue, 17 Oct 2017 10:57:34 +0200 |
> Yes, you would need to follow a common drag-and-drop protocol.
> I don't understand why that is an issue if that is what you want
> to do.
Wasn't that something _you_ wanted to do? If not then we can obviously
ignore it.
> For programmatic purposes when Emacs receives a mouse button
> drag release event, we only care about whether the topmost
> window-system window at the point of release is an Emacs frame
> or not. If at that point, it is occluded by another window,
> we don't care how transparent that window is and whether the
> Emacs frame can be "seen" but only whether it is logically
> the window clicked upon. Again, even if it is not, we can
> process the event as if it were *if we so choose* but having
> the choice is the key issue here.
So I warned here about possible problems with "visibility" once and will
drop this issue.
>> At least for top-level windows. This will work as long a child windows
>>
>> are fully contained by their parents which IIUC is not necessarily true
>>
>> for macOS systems.
>
>
> Could you give a concrete example of where this might be a problem
> so I could test code against it?
Hardly. Child windows are a separate problem because, for example, on X
you currently cannot drop files on them - the drop goes to the parent
window instead.
>>> and (2) a function would be needed to get the attributes of
>>
>>
>> those windows.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> I have figured that part out from the macOS APIs.
Window attributes are a problem on X. You will learn about that as soon
as you try to adapt your code for it.
martin
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, (continued)
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/11
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/11
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, martin rudalics, 2017/10/12
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/12
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, martin rudalics, 2017/10/14
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/14
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/14
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/14
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, martin rudalics, 2017/10/15
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/16
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window,
martin rudalics <=
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/19
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, martin rudalics, 2017/10/20
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Robert Weiner, 2017/10/20
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, martin rudalics, 2017/10/21
- bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window, Richard Stallman, 2017/10/21