Drop doesnt work on Sway #5
Comments
|
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 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. |
It doesn't make sense to drag our own items back into the app itself in sink mode and it only creates a confusing animation, when starting to drag items. The animation is still enabled when dropping. It is a shame that direct QML bindings do not work inside into another ListView. An example of the confusing animation can be seen as an unrelated sideeffect in the demo of #5.
It makes more sense to have blobdrop always floating by default. Otherwise a tiled blobdrop window will look way too large (see demo in #5). Setting the window flag to dialog should usually force a floating window on tiling WMs [0]. [0] rust-windowing/winit#862
|
Thx for your answer! Sorry, indeed, i should clarify, that that is not specific problem of Indeed, Chrome was launched with I did, what u told me to do. I tried to set variable with After that issue resolved. Rn P.S. Can u remind me, is there easyfix, that will force |
It should do that by default now with ee4eac7. |
Thix fix didnt rly work f me. I cloned your repo, build project and it still opens as regular program, not in My system: |
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). |
@HappyCthulhu : This is to be expected in i3 & Sway (and probably other tiling window managers), regardless of X11 or Wayland. To configure an application to open a floating window, it should be configured in the window manager. For example with Manjaro Sway Edition, there is now a default rule for
|
No, that's simply and blatantly false,
No, not only are these workarounds only necessary on Wayland, this entire mindset of "We don't have a way to map this niche usecase in our spec" and "We can't be assed to complete another three year roundtrip of spec bikeshedding that at the end will be blocked anyway by one DE objecting against features that would be considered trivial by any sane person, so we just delegate the effort to the user" is completely backwards and contraproductive for the actual enduser. |
Perhaps to be more accurate with words: If one is using a tiling window manager... one should likely expect most windows to be tiled by default. If one desires to ensure certain windows be always floating instead, one should configure it to be so. (or use applications + EMWH-compliant display server stacks). There's certainly some nuance to navigate between the different display servers, and the support for EWMH and other traditional X11/Xorg features especially concerning Wayland compositors. Clearly there are strong feelings here about this... I was just trying to be helpful to the original poster who appears to be using Manjaro Sway Edition which now has the window rules mentioned above to address this issue. Hope it helps also for those finding this issue via search engine results. 😉 |
I know this is the Wayland way, but again, this is clearly the wrong mindset. What about notifications, menu bars, systrays, overlay panels, PiP windows etc? Obviously the compositor (and with that the user with manual override rules) should have the last word over whether something is floating, but there should be a mechanism for applications to tell what window type they prefer.
There is not even a little bit of nuance here. It's as simple as "It works in X11. It does not work in Wayland, because it doesn't offer a mechanism for this as per usual".
That's fine and manually providing a rule for sway is a good workaround when it does not work out of the box in Wayland. Similar, I was just trying to correct your wrong assessment that this rule would also be needed for i3 (or other X11 tiling WMs), whereas in reality it just works by default there. |
Just to be clear: I didn't intend to add any fuel to the infinite flamewar that is Wayland vs. Xorg. Merely adding some (hopefully) helpful info relevant to the OP's issue for people to find. Clearly you have some opinionated preferences regarding how Xorg's been designed. That's fine... it's still not going to change the current software design of Wayland, nor prevent people from using Wayland if that is their preference to do so.
While I'd agree with you on technical grounds here that it would be nice if applications could express preferences regarding things like floating windows, etc... As I'm sure we both know, these things are being discussed and worked out, and will likely continue to be worked out for years. It's not my place to criticize or defend those design decisions, nor do I want to participate in the flamewar or discuss future Wayland-related protocol or compositor designs. I only intend provide a sort of analysis of how things are working today and what users can do to work around some common issues such as this one. |
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 fpExpected behavior
Dragged object dropped
The text was updated successfully, but these errors were encountered: