(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
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
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
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
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