It is very unlikely that Wine is going to support Wayland in the same way as X. I worked on a Wayland driver for Wine some time ago, but discontinued the idea because Wayland lacks many features that are expected by Windows programs.

One problem is for example that a program can not specify the location of a newly created window. This doesn't sound very problematic at first, until you notice that drop-down / popup menus are also just normal windows on Windows. The solution that Wayland provides for this is not really compatible with the Win32 API. I therefore talked with some Wayland developers and there is no chance of fixing this in the future. It is part of their concept that applications should not have control over the window position and similar settings.

IMHO, it is not a good solution to remove features just because an application could abuse them. 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. It is like removing the possibility to delete files, because the user could accidentally click on the wrong file, instead of implementing a recycle bin. Adding a way to recover from situations in which programs misbehave would be a better solution, but this is just my opinion.

The opinion from the Wayland developers is that you should stick to XWayland. The best solution Wine could offer, would be a virtual desktop that uses native Wayland. Not sure if it is worth the effort though.

(In reply to Michael Müller from comment #1)
> The opinion from the Wayland developers is that you should stick to
> XWayland. The best solution Wine could offer, would be a virtual desktop
> that uses native Wayland. Not sure if it is worth the effort though.

Yeah, sticking to X doesn't sound like a good long term solution.

By making a virtual desktop, do you mean implementing a full blown Wayland compositor in Wine? I also thought that this is one of the options.

(In reply to Shmerl from comment #2)
> By making a virtual desktop, do you mean implementing a full blown Wayland
> compositor in Wine? I also thought that this is one of the options.

No, I mean what you get when you enable the virtual desktop in the graphic tab in winecfg.

Would it be possible map calls into GTK, QT, or equivalent toolkit that know how to draw directly on a wayland buffer?

Xwayland has worked for everything I've tried under it except screen capture applications that need low level X voodoo.  I think the major reason for wine to want to move to native wayland support would be for performance reasons.  I haven't seen any benchmarks that compare native wayland, vs Xwayland, vs Xorg on the same hardware so I don't know which way the winds are currently blowing.  I would expect wayland [at least eventually] to come out ahead.

> Would it be possible map calls into GTK, QT, or equivalent toolkit that know
> how to draw directly on a wayland buffer?

FTR wine-staging has "enable gtk3" tab, so it's probably already started.

> Would it be possible map calls into GTK, QT, or equivalent toolkit that know
> how to draw directly on a wayland buffer?

This would not solve the problem Michael described. These toolkits are able to correctly position drop-down menus because they know which main window the menu belongs to, and can request positioning relative to that. Wine does not generally have this information and would have to guess.

I don't think the problem is insurmountable, but then again I didn't do the work.

Wouldn't then optimal solution be to solve it in wayland compositor ?

I suppose folks would have to agree on some sort of standard interface to wine that could be implemented on all compositors...

Wayland clients have control over the position and size of sub-surfaces. Would it be feasible to use sub-surfaces for drop-down/popup menus?