Drop doesnt work on Sway
HappyCthulhu opened this issue · comments
Describe the bug
Hello. I switched to sway few weeks ago. Im in love with CLI-tools, that allow me to drag&drop from CLI, but im expiriencing troobles with that on Wayland. Drag window shows up, but i cant drop anything. Sometimes i can, sometimes - cant. Can u suggest some solution for me? Or, at least, tell me, how to debug it properly.
Demonstration:
183dc8a3-3ce6-411d-a4ae-3a9c540ca0e9.mp4
To reproduce
blobdrop fp
- drag it
Expected behavior
Dragged object dropped
That looks broken, the circular animation should also only show when you drop something in blobdrop (in sink mode) rather than the other way around (Edit: That was a regression apparently).
On Wayland things are a bit tricky, but your shown workflow should still work on Wayland. Is blobdrop started in XWayland or in Wayland mode? You can force the former with QT_QPA_PLATFORM=xcb
, the latter with QT_QPA_PLATFORM=wayland
.
Is Google Chrome running in Wayland or XWayland mode?
Edit: Given the other two issues you opened ([0] [1]), I suspect that this is not an issue in blobdrop but rather with Chrome running in XWayland, while blobdrop is running in native Wayland mode.
If that is the case, you can either try starting Chrome in native Wayland mode, or alternatively blame the Wayland folks for still not having fixed DnD between XWayland and Wayland in 2024.
Thx for your answer! Sorry, indeed, i should clarify, that that is not specific problem of blobdrop
.
Indeed, Chrome was launched with XWayland
(i found out that with xeyes
, xorg-xwininfo
, extramaus
)
I did, what u told me to do. I tried to set variable with set QT_QPA_PLATFORM wayland
if my fish-shell, than - launched google-chrome-stable
from this shell. This approach didnt work - google-chrome-stable
continued to launch via XWayland
. Then, in chrome://flags, i changed Preferred Ozone platform
from Default
option to Wayland
.
After that issue resolved. Rn blobdrop
and dragon
works well, dropping part is happening)
P.S. Can u remind me, is there easyfix, that will force blobdrop
opened as float
-window, not as regular window? Dragon
opens as float
from the box, but blobdrop
- not.
P.S.S Lets close this issue in few days, not rn, ok? Give me some time, mb issue will reproduce again later.
is there easyfix, that will force
blobdrop
opened asfloat
-window, not as regular window?
It should do that by default now with ee4eac7.
You just need to update your blobdrop version, which depends on what distro you are using I guess.
It should do that by default now with ee4eac7. You just need to update your blobdrop version, which depends on what distro you are using I guess.
Thix fix didnt rly work f me. I cloned your repo, build project and it still opens as regular program, not in float
mode.
My system:
[I] user@t-t14 ~> neofetch
██████████████████ ████████ user@t-t14
██████████████████ ████████ ------------
██████████████████ ████████ OS: Manjaro Linux x86_64
██████████████████ ████████ Host: 21CGS1HJ00 ThinkPad T14 Gen 3
████████ ████████ Kernel: 6.1.80-1-MANJARO
████████ ████████ ████████ Uptime: 12 hours, 57 mins
████████ ████████ ████████ Packages: 1778 (pacman), 5 (flatpak)
████████ ████████ ████████ Shell: fish 3.7.0
████████ ████████ ████████ Resolution: 3840x2160
████████ ████████ ████████ WM: sway
████████ ████████ ████████ Theme: Adapta-Nokto-Eta-Maia [GTK2/3]
████████ ████████ ████████ Icons: Papirus-Adapta-Nokto-Maia [GTK2/3]
████████ ████████ ████████ Terminal: tmux
████████ ████████ ████████ CPU: AMD Ryzen 7 PRO 6850U with Radeon Graphics (16) @ 2.700GHz
GPU: AMD ATI Radeon 680M
Memory: 8621MiB / 30849MiB
This fix didnt really work for me.
Right, it will only work on X11 window managers. This is not a problem of blobdrop, but again a Wayland problem. Unlike X11, Wayland does not have support for window types that signal to the window manager that an app wants to be in floating state, see: rust-windowing/winit#862 (comment)
Some applications use a workaround to mark them as non-resizable, which will cause Sway to skip tiling them. But I explicitly want the window to be resizable, so I will not use this workaround.
Feel free to open a Merge Request to wayland-protocols. Maybe if you have luck, it won't be bikeshed for 3 years, before being ultimately closed because one party doesn't agree with such basic features for your secure display server.
In any case, this is all going beyond the scope of the original issue (which was about attempting to drag between Wayland and XWayland windows).