PS: I've noticed that winit never destroys any wayland surfaces. I've kept it that way with the new objects I've added.

@mahkoh winit should destroy the surface via sctk iirc, unless sctk changed that?

I don't see anything wrong in destroying those, but there might be a reason why it's that way.

In general, unless the protocol will be accepted there won't be any action on that PR.

@mahkoh winit should destroy the surface via sctk iirc, unless sctk changed that?

I don't believe this applies to the wl_surface itself.

I don't believe this applies to the wl_surface itself.

Ah, I think it doesn't destroy it in the Window, since it's basically a handle, yeah, should do that, would you send a patch against master or I should do so?

Please go ahead. I'll add destructor calls for the new objects I've added in this PR.

@mahkoh it's being dropped here https://github.com/Smithay/client-toolkit/blob/f03c4b7dea89648dbcba43de80eb14687e0e9da8/src/shell/xdg.rs#L139, so no need for winit to drop it explicitly as well.

self.surface refers to an xdg_surface not to a wl_surface.

Hm, you're right. I've confused the place, but as well as the surface that is being dropped by sctk, since the one it's dropping is invisible one for decorations. So yeah, we should drop this surface in winit.

Keep in mind that the wl_surface must be destroyed after the xdg_surface. Otherwise a protocol error occurs.

@mahkoh In general I have a question, how that will work with client side decorations winit is drawing and sctk frame integrations? I think they should be aware of that change somehow?

They continue to be rendered at integer scales (usually the fractional scale rounded up.) In my tests I did not see any problems with that.

I mean, they should likely scale font if they do font rendering to account for that? That's not the with default sctk decorations, but it's the case with adwaita frame.

In general I'd not take any action further here, unless the protocol get merged and sctk get a release...

I mean, they should likely scale font if they do font rendering to account for that?

Yes, they scale the font at the next integer scale.

In general I'd not take any action further here, unless the protocol get merged and sctk get a release...

This has nothing to do with sctk. It provides a strict improvement for the content of the window while leaving the frame unchanged.

There will be at least one breaking change in the protocol: The scale type has been changed from fixed to uint with a denominator of 120. I will try to adapt this PR soon.

@mahkoh I'd assume stabilization is soon™

Incidentally working on rebasing this right now.

The protocol has been accepted.

@mahkoh I'd wait until the sway merges their stuff wrt fractional scaling so I'd have easier time testing it. Given that implementation isn't in wlroots yet it may take some time, but we're not in the rush anyway.

For now just schedule it for winit 0.28.

Updated with the final protocol text. The SDL implementation has been merged: libsdl-org/SDL#5906

What is the timeline for 0.28?

Added the missing destroy calls for the add-on objects. See #2369 (comment)

What is the timeline for 0.28?

There's no timeline.

I'd basically wait for sway to get fractional scaling, if it won't and we'll be doing 0.28 I'll go back to it.

I'd basically wait for sway to get fractional scaling, if it won't and we'll be doing 0.28 I'll go back to it.

Note that KDE/kwin has already merged the implementation of fractional scaling and it would be available since the next release (5.27). I hope we can get it in soon.

@mahkoh I could finish this PR myself given that everything is more of a codestyle rant. Just let me know (though I'd push anyway in-before release).

Sorry I'm busy with work at the moment. If you could finish it that would be great.

Applied.

Thanks.