Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

2018-03-03 Thread Quentin Glidic
(I wonder if Pekka or Daniel would like to be dropped off the CC list as it may be too desktop-ish for them?) On 3/3/18 10:58 AM, Simon Ser wrote: Hi, Thanks for taking time reviewing the protocol and suggesting an alternative design. On March 2, 2018 4:36 PM, Mike Blumenkrantz

Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

2018-03-03 Thread Simon Ser
Hi, Thanks for taking time reviewing the protocol and suggesting an alternative design. On March 2, 2018 4:36 PM, Mike Blumenkrantz wrote: > Hi, > > I agree with your point regarding a SSD-capable compositor not always wanting > them, and certainly I can see

Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

2018-03-02 Thread Mike Blumenkrantz
Hi, I agree with your point regarding a SSD-capable compositor not always wanting them, and certainly I can see the usefulness for cases such as what you've cited. However, in the example you provided, it's easy enough for an application to determine what desktop it's running in and then

Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

2018-03-01 Thread Simon Ser
Hi Mike, I don't think a compositor supporting the protocol means that it always wants SSDs. For instance, I can imagine a DE like GNOME supporting it: - Allowing clients that prefer SSDs to use SSDs, so that toolkits like GLFW or winit and apps like mpv don't have to draw decorations that'll

Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

2018-03-01 Thread Mike Blumenkrantz
Hi, This patch is certainly an improvement upon the previous protocol draft which I reviewed, but it still does not address the most significant issue that I pointed out, which is that it both is too complex and lacks features. Why is there any "mode" when this is a protocol for enabling