Child windows on Wayland #3487
Child windows on Wayland #3487
Conversation
|
I'd just note that I was planning to do child windows myself in or after 0.31.0 since they are a bit complex to get right cross platform. The present winit is not really suited for them and they are a bit hacked up in other backends. Probably the same reason you don't see them on macOS. popups are also not suited with the architecture we have right now. Clipping with viewporter doesn't sound like a really good idea, Though, I understand where it's coming from. I also believe that you can control clipping on other platforms, but it's a bit special. |
Co-authored-by: daxpedda <[email protected]> Closes: rust-windowing#3448
Mainly fix typos in comments, but also some minor code changes: * Rename `apply_on_poiner` to `apply_on_pointer`. * Rename `ImeState::Commited` to `ImeState::Committed` * Correct `cfg_attr` usage: `wayland_platfrom` -> `wayland_platform`.
|
Seems to be working for the most part, but subsurfaces don't seem to pick up seat events like they're supposed to. (unless I'm missing something) EDIT: Apparently Wayland is sending the events, but they aren't picked up by winit |
|
I'd just not that I don't have real interest to look into subsurfaces especially how messy they get due to a fact that making subsurface a regular window is a design PITA, the same goes for other child windows that were hacked up. In general, I can do all of that myself with a proper API in 0.31.0, because making people rely and design around broken API is not what I want. |
jgcodes2020
requested review from
jackpot51,
msiglreith,
daxpedda,
madsmtm,
kchibisov and
notgull
as code owners
There was a problem hiding this comment.
Thanks for your work.
But as I said multiple times the way you try to implement it into what we have now is just an unmaintainable mess, which is not your fault, but rather the toplevel API design, since regular window and subview is treated the same, while in reality it's not the case.
The set of APIs is completely different, the semantics are also different, and the fact that subview never has focus, but has pointer focus is also not really expressed. The relationships are not really clear, the lifetime between child and parent are not directly exposed leading to unsound code, so I'd rather not users rely on things like that and do proper API for all platforms with 0.31.0 release.
If you want to continue working on child windows, I'd suggest to look into creating common cross platform API detached from the window itself, and how parent/child should be communicated through out winit events, since it's basically undefined as it is now.
Looking at #3433 and where parts of this PR fit in, I'd need to wait until this step:
This is where we'd write a |
Can follow this #3506 . The X11/Windows backends tricked child windows to be what they shouldn't be, because it was more about toplevel parent, but it end up with subsurface like API. And setting toplevel as a parent is not supported in winit, but I think you can do so in the wayland protocol sense. |
Emacs has a well tested child window design and well documented. |
|
I'll close this PR and open an issue to discuss how we can support child windows and popups. |
CHANGELOG.mdif knowledge of this change could be valuable to usersThis PR will add child windows on Wayland via the
wl_subsurfacerole. Below are design issues I'd like to work out before starting work.wl_subsurfaces aren't clipped to their parent. Do we want to implement clipping client-side viawp_viewport?