On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote: > This changes the semantics in a non-backward compatible way; clients > relying on the currently defined behavior would break, so I'll have to > nack this change. You'd have to add a `set_fullscreen_translucent` or > something like that if the described behavior is needed.
To re-use an argument that was brought up in the xdg-decoration discussion: compositors are just going to do whatever they want here, and this sets up expectations accordingly. Wayfire already disregards this clause, and consider this an announcement of Sway's intentions do to the same. In any case, I don't think this grossly affects the behavior clients have come to rely on. I sought some feedback on this patch privately before posting it to consider these concerns upfront. The main use-case for the original wording was found to be media players which rely on this behavior for letterboxing when the aspect ratio between the output and the video differs - which is addressed in the proposed wording. Additionally, the original wording never made any promises as to the relationship between the fullscreened surface and the output its shown on. One notable example is that the unreliability of wl_output's width/height specifications forces (correctly so) users to continue to use configure events to communicate the desired size. This is especially necessary with non-traditional outputs like VR headsets. Implementation details like direct scan-out, which is only possible given the constraints in the original wording, aren't actually guaranteed - but are not ruled out by the new wording. What do you think? Does that rationale make more sense? _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
