vimpostor / blobdrop

Drag and drop files directly out of the terminal

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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 as float-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).