15 ms·

Essentially because many Windows APIs are unimplementable in Wayland. Here is some discussion in Wine's bugtracker: https://bugs.winehq.org/show_bug.cgi?id=422

Essentially because many Windows APIs are unimplementable in Wayland. Here is some discussion in Wine's bugtracker: https://bugs.winehq.org/show_bug.cgi?id=42284 https://bugs.winehq.org/show_bug.cgi?id=42284

solarkraft 8y ago
One complaint in this specific thread is that applications can't control the location of their surfaces (which is needed for things like drop-downs and tool tips), but then again sub-surfaces can be controlled by the parent surface. This specific problem does look solveable.
- makomk 8y ago
  As I understand it from that bug report, the problem is that the Windows app doesn't have to provide any link between the menu or tooltip and the window it's from that's visible to Wine. So your solution basically boils down to modifying every Windows app out there to make it Wayland-compatible, potentially including a bunch of niche industry-specific or even company-specific ones. There's a similar problem with implementing X on top of Wayland, and so XWayland has special powers that normal apps don't in order to be able to work. That's why running Wine as an X client under XWayland doesn't have this problem.
platz 8y ago
> One problem is for example that a program can not specify the location of a newly created window. > It is part of their concept that applications should not have control over the window position and similar settings. > I can understand this for security relevant features, like grabbing the keyboard and mouse input from another window, but not for things like specifying the window position Seems excessive
- dkersten 8y ago
  As a user and big fan of tiling window managers, I want the window manager to be the one deciding where windows are positioned, not the application that owns the window. But hey, we can have different tastes and preferences.
  - platz 8y ago
    That's fine for the majority of Linux apps, but being so strict could impact cross-platform apps that don't understand those assumptions, and then they don't work well at all. For example, the interactive brokers Java application is written in a cross-platform way that makes use of many popup menus. I would hate my choice of wm saying, no, you cannot effectively use this software because it doesn't conform to our windowing constraints. And yes, I use i3, so I am a fan of tiling windomanagers too. Not everything nicely fits into such a box though, and it's better err on the side of compatibility here, than say, can't use that app, sorry
    - pmoriarty 8y ago
      In those cases, why not just have the window manager lie to the application and say, effectively, "your request to position the window at the coordinates you specify has been fulfilled", but actually position the window where the window manager wants? That way those java apps would still work, right?
      - platz 8y ago
        Sure, if it actually works
  - TheReverend403 8y ago
    > I want the window manager to be the one deciding where windows are positioned It still can, the client merely gives size hints. It is entirely up to the window manager whether it honours them.

solarkraft 8y ago

One complaint in this specific thread is that applications can't control the location of their surfaces (which is needed for things like drop-downs and tool tips), but then again sub-surfaces can be controlled by the parent surface. This specific problem does look solveable.

makomk 8y ago
As I understand it from that bug report, the problem is that the Windows app doesn't have to provide any link between the menu or tooltip and the window it's from that's visible to Wine. So your solution basically boils down to modifying every Windows app out there to make it Wayland-compatible, potentially including a bunch of niche industry-specific or even company-specific ones. There's a similar problem with implementing X on top of Wayland, and so XWayland has special powers that normal apps don't in order to be able to work. That's why running Wine as an X client under XWayland doesn't have this problem.

platz 8y ago

> One problem is for example that a program can not specify the location of a newly created window. > It is part of their concept that applications should not have control over the window position and similar settings. > I can understand this for security relevant features, like grabbing the keyboard and mouse input from another window, but not for things like specifying the window position Seems excessive

dkersten 8y ago
As a user and big fan of tiling window managers, I want the window manager to be the one deciding where windows are positioned, not the application that owns the window. But hey, we can have different tastes and preferences.
- platz 8y ago
  That's fine for the majority of Linux apps, but being so strict could impact cross-platform apps that don't understand those assumptions, and then they don't work well at all. For example, the interactive brokers Java application is written in a cross-platform way that makes use of many popup menus. I would hate my choice of wm saying, no, you cannot effectively use this software because it doesn't conform to our windowing constraints. And yes, I use i3, so I am a fan of tiling windomanagers too. Not everything nicely fits into such a box though, and it's better err on the side of compatibility here, than say, can't use that app, sorry
  - pmoriarty 8y ago
    In those cases, why not just have the window manager lie to the application and say, effectively, "your request to position the window at the coordinates you specify has been fulfilled", but actually position the window where the window manager wants? That way those java apps would still work, right?
    - platz 8y ago
      Sure, if it actually works
- TheReverend403 8y ago
  > I want the window manager to be the one deciding where windows are positioned It still can, the client merely gives size hints. It is entirely up to the window manager whether it honours them.