On 19/11/14 04:41 PM, Bill Spitzak wrote: > On 11/19/2014 07:16 AM, Derek Foreman wrote: > >> I'm pretty sure the mouse may have already moved - exactly the same >> reason as above, this handler is getting the drop co-ords but time has >> passed since the drop. > > You are right about that. I'm not clear on how input_get_position is > implemented, did the client record the position of each input, or is > this some sort of round-trip to the server? If the latter it probably > should be done differently such as recording it in the motion handler. > > I think you need to change all input cursors when dnd_add_item is > executed for any reason. Any of them may have changed from a pointer to > a hand. Imagine if there are two pointers and one is used to drop the > data at the same location the other is pointing at. So there is no need > to record the last input, you have to change them all.
Multi pointer. Sweet. Guess what, it's not just the cursor that's messed up - the translucency of the dragged item may be wrong if an item gets dropped beneath it, or picked up from beneath it. > You have to not change the mouse cursor on move and enter events while > waiting for the data. You must not lose the dragged flower until the > actual flower appears. I don't understand this requirement - if I don't change the mouse cursor on enter events while waiting then the cursor will be wrong if a flower is right at the edge of the window. I need to make sure I don't change the mouse cursor of any mouse that's actually dragging an object, I think... But they should receive a leave event pretty much immediately at drag start. Except they don't - if you're moving the mouse and pick up an item on the fly the cursor is wrong. I guess because the drag start involves creating the surface to be dragged, so motion can occur between the click and that actually happening in the server. > If there are multiple pointers, it actually looks like it is best if you > don't change any of them while waiting for the drop data. This will > reduce the number of transitions they go through. It also appears there > is a need for stacking order of pointers, the drop one should be on the > bottom? I think pointer stacking order is probably a different issue and won't be dealt with in the dnd example client? Not sure at all how that should be handled, if at all. Who's on top: Last click? Last enter? Last motion? And, ultimately, does anyone care enough to define what "correct" pointer stacking order should be? :) > To really remove any possibility of flicker the client also needs to > enter pointer-lock mode (assuming it works as I want, which is to make > no changes but to stop moving the cursor except in response to > positioning commands from the client). This will stop the drop cursor > image from moving away from the drop location if the user moves the > mouse before the drop finishes. This may need some server support so the > cursor stops moving at the time of the drop. The drop cursor image is just the four way arrow, I don't think it's a really big deal if it diverges a bit from where the dropped item is about to appear? The cursor sticking in place would probably be more annoying... _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
