[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Collaboration on standard Wayland protocol extensions
From:       Drew DeVault <sir () cmpwn ! com>
Date:       2016-03-29 12:14:25
Message-ID: 20160329121425.GE1068 () homura ! home ! eatonfiles ! com
[Download RAW message or body]

On 2016-03-29 10:25 AM, Martin Graesslin wrote:
> > - More detailed surface roles (should it be floating, is it a modal,
> > does it want to draw its own decorations, etc)
> 
> Concerning own decoration we have implemented https://quickgit.kde.org/?
> p=kwayland.git&a=blob&h=8bc106c7c42a40f71dad9a884824a7a9899e7b2f&hb=818e320bd99867ea9c831edfb68c9671ef7dfc47&f=src
>  %2Fclient%2Fprotocols%2Fserver-decoration.xml

Excellent. The protocol looks like it'll do just fine.

> I think especially for compositors like sway that can be very helpful. For Qt 
> we implemented support in our QPT plugin for Plasma. So if sway wants to use 
> it I can give you pointers on how to use it in your own QPT plugin (if you 
> don't have one yet how to create it) and to use it to force QtWayland to not 
> use the client side decorations.

I would love to see something like that. Can we work on a model that
would avoid making users install qt to install Sway? Honestly I'd like
to just set an environment variable to turn off CSD where possible, for
both Qt and GTK. I'm still trying to avoid forcing a toolkit on users.

--
Drew DeVault
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]