Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arbitrary blank panel positions in module menu after dragging modules #17478

Closed
MStraeten opened this issue Sep 15, 2024 · 4 comments · Fixed by #17467
Closed

arbitrary blank panel positions in module menu after dragging modules #17478

MStraeten opened this issue Sep 15, 2024 · 4 comments · Fixed by #17467

Comments

@MStraeten
Copy link
Collaborator

MStraeten commented Sep 15, 2024

Describe the bug

with new panel control several blank module positions occurs in the right module menu.
seems to occur if a module is moved by drag and drop (formerly this requested ctrl+shift) and additional blanks on further drag of a module (even the module keeps in its place)
image
unfortunately there doesn't seem to be a way to get rid of it/them again

Steps to reproduce

  1. klick and drag a module in darkroom module menu

darktable version

4.9.0+501~g02a5e6b2f3-dirty

What OS are you using?

Mac

What is the version of your OS?

macos 14

@dterrahe
Copy link
Member

Could you please try if #17467 helps? I can't test on Apple myself. The order gtk sends drag&drop messages seems to vary and might be completely different again on macos. Thanks!

@MStraeten
Copy link
Collaborator Author

the behaviour now occurs only if a module is shifted to a new pixel pipe position; then each shift results in a blank place above or below the shifted module.
so doesn't help ...

@dterrahe
Copy link
Member

Could you please test for me if adding the && !below to the 3rd line of dtgtk_expander_set_drag_hover helps, so that it reads

  if(!widget || (!allow && !below && widget == _drop_widget && time == last_time)) return;

I suspect that on mac the last motion event, the drop event and the drag-end event are all delivered with the same timestamp, whereas for me (on debian and windows) they are always different, so I got away with the simpler check.

@MStraeten
Copy link
Collaborator Author

yes, that addition gives a proper behaviour

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants