• LeFantome@programming.dev
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      12 hours ago

      Clearly not a bug. “Should” is a clear feature request.

      I am not saying they should not do it. Maybe they have. But closing the “bug” was the right thing to do.

      Bugs and feature requests need to be prioritized and processed quite differently.

    • Lojcs@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      13 hours ago

      I just tried this and it seems mostly fixed? Focus changes on button down but the window is raised on button up

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        12 hours ago

        That’s definitely better, but still not as good as Windows. If you click on an area that isn’t a drag source it should be raised on button down. I presume it doesn’t do that?

    • A_norny_mousse@feddit.org
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      17 hours ago

      I would not want to call this a bug. It’s a limitation at worst.
      And even after reading to the end I have no idea if it’s dictated by kwin itself or by the underlying server.
      It has accumulated slightly different complaints from different users to the point that the discussion became muddied.
      One dev pointed out that the underlying gui server disallows this behavior, but during the discussion it has become increasingly unclear what “this behavior” even is, or what the “supposedly easy” fix would be.

      My thoughts/experience:

      • my window manager (under Xorg) can be configured to react differently on mouse-up or mouse-down. Whether one clicks on the client window or titlebar doesn’t matter, it goes to the wm first.
      • the supposedly unsolveable problem practically never happens to me because I like to arrange my windows side-by-side, on different workspaces etc. but never on top of each other.
      • lastly, dragging and dropping between application windows used to be so hit and miss on Linux that I stopped doing it at all, or at least not expecting it to succeed. No idea if it got better in the past decade. This might have something to do with the fact that I’m not using a full-blown DE.

      Question to you: is the desired behavior possible to achieve with some other WM? Can you disprove the claim made by one or two of the devs, that it just isn’t possible to solve within kwin/KDE because the underlying graphical server is responsible for this limitation?

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        16 hours ago

        So, Windows has fully optimal behaviour here:

        If you click on an area of the window that cannot be dragged from, it raises it on mouse-down.

        If you click on an area of the window that can be dragged on, it doesn’t raise if you start a drag, otherwise it raises it on mouse-up.

        That’s the desired behaviour. I agree people didn’t really explain that clearly.

        I haven’t looked into it for over 20 years but as I recall it is impossible to do this with X11. I have no idea if Wayland added some kind of support for this, but I would be quite surprised given how long it took them to do screenshots.

        Part of the difficulty is that you need to somehow query an app on mouse-down if it might start a drag. I have no idea how Windows does that… but… they solved it decades ago.