Prevent cards jumping around while dragging about cockatrice

[tooomm]

The video looks very promising. I like the position highlighting a lot, that's great!
Way more intuitive than what we currently do.

One thing I notice in your recording:
The card stack should not be pushed away further to the right at ~0:13 though (from position 3 to 4)?
But instead jump back to its initial start placement (position 2) as the card is now hovering "position 3" on the grid which was empty in the beginning.
But if that's tricky to figure out, I'm totally fine with what we see in the clip.

Can you explain the issues you spotted a bit more?

[Elarnon]

The video looks very promising. I like the position highlighting a lot, that's great! Way more intuitive than what we currently do.

One thing I notice in your recording: The card stack should not be pushed away further to the right at ~0:13 though (from position 3 to 4)? But instead jump back to its initial start placement (position 2) as the card is now hovering "position 3" on the grid which was empty in the beginning. But if that's tricky to figure out, I'm totally fine with what we see in the clip.

That is because the card stack is too big; if we did that, the stack would move back to its initial position but the cursor would still be over the stack which we wanted to avoid. But I agree, it ends up causing somewhat weird behavior (and it actually complicates the math quite a bit, so I'd be happy to remove that).

Can you explain the issues you spotted a bit more?

In the video I do not change the zoom level dynamically and you can see the cards overflow the table (around 0:13). Trying to resize the table dynamically causes two kinds of issues:

• Resizing inside the mouseMove event handler seems to trigger new mouseMove events while inside the handler (even though the mouse did not move on the screen, it moved relative to the QGraphicsScene viewport), which the code used in the clip is not equipped to handle but that should not be too hard to fix;
• This kind of dynamic zoom is prone to "flip-flopping" issues where zooming out could cause the mouse to move relative to the scene which could cause it to cross a boundary that would change the place the card would go, which would mean we no longer need to zoom out, so we would zoom back in, but that would cause the target position to change again, which would mean we do need to zoom out, etc.

I think I see a way to write the math in a way that would prevent the flip-flopping issue horizontally, but I don't see how to prevent it vertically (i.e. if card displacement requires zooming out, but zooming out causes the cursor to go over another row where there is space and no displacement is needed, which would cause us to zoom back in etc.).

The best compromise I can see (outside of not zooming and living with the occasional overflow) is:

• Prevent ever displacing cards by more than 1 column (see your first remark);
• When card drag starts, compute the zoom level as if the card was placed at the rightmost accessible table position (this is relevant when dragging a card with attachments, which is wider than a regular card)

I don't like it very much (it would cause more zoom than necessary) but I believe this would be enough to ensure we never overflow the table.

A (IMO, better) alternative would be to set the zoom level inside each row independently, so that the (horizontal) boundaries between rows do not change — but that is not possible given the current architecture where we only change the zoom level of the whole scene.