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

[Eike Hein]

On 07/04/2018 11:45 PM, Jonas Ådahl wrote:
> Looks good to me, I think we can go with this. What Reviewed-by:s should
> I add, besides my own?


Reviewed-by: Eike Hein 


> Jonas

Thanks,
Eike Hein
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

Reviewed-by: Eike Hein <h...@kde.org>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Add layer-shell-unstable-v1.xml

[Eike Hein]

On May 8, 2018 6:23:30 PM GMT+09:00, "Jonas Ådahl"  wrote:

>It is my opinion that we should continue with the scope described
>above,
>to make a clear separation between what portable clients can expect
>while expecting to work both on highly integrated environments and less
>integrated environments alike.

I understand wanting to avoid a scenario where every compositor collapses under 
peer pressure to implement every protocol under the sun, but a think it's a 
secondary concern to the "lots of junk in many private silos" problem.

There's a lot of value to subsets of the greater Wayland implementation 
community collaborating and agreeing on things when they have overlapping needs 
(which they do, as can be shown by example). Compared to keeping protocols to 
ourselves which could easily interest multiple stakeholders, it leads to 
better, more generic protocols that compose/complement better, while avoiding 
redundancy. It means accumulating less tech debt across a lot of software, 
which is ultimately good for users.

It's good for wayland-protocols to be the space this happens in, because it's 
where the necessary engineering culture exists to hold protocol development to 
consistent quality standards. And that's without getting into the 
interoperability benefits.

Limiting wayland-protocols to "expected to implement/be provided" protocols is 
that it doesn't allow all this good stuff to happen. At the very least there's 
definitely ways to avoid unmitigated sprawl, e.g. checklists to avoid redundant 
protocols and "does too much" protocols. The peer pressure problem I'm not sure 
how to address, but I am also not convinced it'd actually materialize in 
practice. In reality when it does it'd usually be driven by users wishing to 
get things to interoperate, which indicates a need, which should be met somehow 
and to the best quality possible - cf. xdg-toplevel-decoration.

I understand the worry about getting swept away by a tide that won't be 
stemmed. But right now there's more desire for collaboration than there is a 
venue for, and I'm more worried about the opportunity cost to protocol and 
software quality that comes with it. If in doubt, maximizing collaboration 
usually makes for more durable stuff.

layer-shell: We are interested. It does things we already have working with a 
protocol proprietary to Plasma, but better, as it's more focused and 
generalized and has seen more review already than we could muster internally at 
the time. Between that and the users who are asking us for more 
interoperability whenever possible it's attractive.

Cheers,
Eike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Finding a window's icon

[Eike Hein]

On 04/26/2018 07:49 AM, Nicholas Bishop wrote:
> My question is, does that work in practice? Do most applications
> actually set the application ID as suggested?

KDE/Qt and Gnome/GTK apps generally do. We've had to poke a few
apps in the broader ecosystem to fix things, but overall things
are a bit better and not any less reliable than the equivalent
.desktop<->WM_CLASS mapping on X.


Cheers,
Eike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

On 03/24/2018 08:08 PM, Simon Ser wrote:
> This adds a new protocol to negotiate server-side rendering of window
> decorations for xdg-toplevels. This allows compositors that want to draw
> decorations themselves to send their preference to clients, and clients that
> prefer server-side decorations to request them.
> 
> This is inspired by a protocol from KDE [1] which has been implemented in
> KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> provides an updated protocol with those concerns taken into account.
> 
> Signed-off-by: Simon Ser <cont...@emersion.fr>
> Reviewed-by: Drew DeVault <s...@cmpwn.com>
> Reviewed-by: David Edmundson <da...@davidedmundson.co.uk>
> Reviewed-by: Alan Griffiths <alan.griffi...@canonical.com>
> Reviewed-by: Tony Crisci <t...@dubstepdish.com>


Forgotten in my previous reply:

Reviewed-by: Eike Hein <h...@kde.org>


Cheers,
Eike Hein
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

+1

I quite like this one. It's the best version so far.



Cheers,
Eike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

>> If server and client do not negotiate the use of a server-side
>> decoration using this protocol, clients continue to self-decorate as
>> they see fit."
>
> The wording here is weird, and I want to avoid the word decorate. What
> the client does is not necessarily decorate. The reason why clients
> would need to decorate themselves at all is to give the user some visual
> cues for their true purpose: window management. We should just say this.
> I prefer my previous wording:
>
>> If the client chooses not to use server-side decorations, it is
>> responsible for its own window management operations.
Up-front: I could live with that one if need be.

... but I think it's sort of inviting some trouble again. "Window
management operations" gets us - albeit in a much less specific way,
which is a big improvement - back into the territory of defining
"decoration". The use of "responsible" also creates an expectation that
a client will cater to window management in some way, which some clients
have shown a preference for not doing. I think my version captures
reality in a better way without holding anyone to new requirements that
didn't exist before today.

The spirit of my para was two communicate two things:

* This is an optional additional negotiation that takes place between
server and client that allows them to agree on the client being
server-decorated.

That means servers who don't care are unaffected and clients which don't
care are unaffected, which is what we want because we can't universally
agree on any specific case, but we can agree that Wayland should let us
all build the systems we envision. What it does allow is for components
that do agree to work together, which is a big step in the right direction.

* If this negotiation does not take place or does not have this result
(server does not implement at all, preferred mode is client-side, client
doesn't request server-side), clients are left to do whatever.

The wording of my second clause also implies - but does not enforce,
since it has no mechanism to do this anyway - that if client and server
agree on server-side decoration, a client should probably not decorate,
which I think is good to have in there in spirit.



Cheers,
Eike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

How about:




And as description:

"This interface allows a server to announce support for server-side
decorations and optionally express a preference for using them.

A client can use this protocol to request being decorated by a
supporting server.

If server and client do not negotiate the use of a server-side
decoration using this protocol, clients continue to self-decorate as
they see fit."

Cheers,
Eike


On 03/19/2018 04:34 AM, Drew DeVault wrote:
> To summarize the state of affairs here, the purpose of this protocol is
> to communicate:
> 
> - The compositor's preference to use SSD or leave the client to its own
>   devices
> - The choice of the client to have SSD displayed
> 
> We can completely remove CSD from the question because the term is
> barely meaningful. CSD is just a code-word for "some client-provided
> mechanism for window manipulation". SSD on the other hand is an apt
> description for what the server is going to do here.
> 
> I think we can settle the matter by making the following change to
> Simon's proposal:
> 
> 
>   
> These values describe window decoration modes.
>   
> - 
> - 
> + 
> + 
> 
> 
> Then updating the prose accordingly. We can include a note along the
> lines of "if the client chooses not to use server-side decorations, it
> is responsible for its own window management operations."
> 
> --
> Drew DeVault
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

On 03/18/2018 03:55 PM, Markus Ongyerth wrote:
>> a) Change the definition of "decoration" to "window controls as deemed
>> appropriate by the compositor, for example ...". This leaves what's in a
>> server-side deco and what's in a client-side deco up to servers and
>> clients, respectively, and allows this protocol to serve more systems.
> While a bit of rewording here (probably to the ambigous state it's in 
> xdg-shell) wouldn't hurt, this particular sentence would make CSD very weird, 
> since the client doesn't know what the compositor deems appropriate.
> I think we should avoid the situation where clients try to guess their env, 
> not promote it even further.

I hear you, but I don't think it's a problem - hang on.

Let's try to cut through all the heated contention we've had going on:
One of the issues some people in the "SSD camp" have is that in their
minds, "CSD" means whatever GTK+ 3 is doing with header bars, since
that's the most prominent example around.

But in a wayland-devel context, to paraphrase someone from #wayland, CSD
actually just means "the client is expected to draw whatever decoration
it deems fit for its uses" (which could include "nothing at all").

So you have two different models of thought:

a) Systems where the compositor wants to put standardized decorations on
clients to enforce/enable particular behavior and/or workflow across all
of them.

b) Systems where the compositor takes the stance of "the client knows
best how it wants to decorate itself".

In my eyes this protocol is about negotiating between these two cases,
and that's where my proposed wording comes from. If the server
advertises this interface, a client can opt into "I agree I'm not going
to decorate myself and let you do it", or the client can be left to its
own devices.

I think in both case, the protocol shouldn't make any attempts at
specifying what either the server or the client should put into a
decoration, which is what the text does right now. I think it's both
unnecessary and constrains us in a way we don't actually want. This
should be removed from the protocol text.

Plus, there's a chance here to go 180 degrees from the current wording
and describe the non-server-decorated case as "client shall decorate
itself as it sees fit" explicitly, which is obvious to some of the
Wayland community but not all, and could help with finally putting all
this in-fighting behind us. Without introducing any new side-effects in
the process (I think that's a free bonus, mind you - the main motivation
is just engineering hygiene).


Cheers,
Eike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

On 03/18/2018 10:45 PM, Daniel Stone wrote:
> That strikes me as a problem. So what can we do to bridge the gap
> between these projects?

FWIW, I agree this is a problem. KDE's Wayland contributor base is
slowly growing, though - we have more people working on Wayland stuff
than we had previously, and across more products which rely on it
exclusively (e.g. Plasma Mobile) - and I'm optimistic this is going to
lead to us talking more, talking earlier, and taking more responsibility
for shepherding the stack, together.

I'm also wondering if a shared "Planet Wayland" blog aggregator would
make sense, and subscribing implementers from across the community to it
- currently you have to take some more active steps to follow content
published by people who solve interesting problems with Wayland, and
regretably, perhaps the best way to discover them is whenever they cause
drama on r/linux. That's a rather poor state of affairs.


Cheers,
Eike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Eike Hein]

On 03/16/2018 12:43 AM, Daniel Stone wrote:> No, it really has. GTK+ has
always - well, until you got the patches
> for this protocol merged a month or two ago - decorated its own
> windows under Wayland. Same with Qt. Same with EFL. These are toolkits
> which have been around and deployed for several years, doing exactly
> what I'm describing. Sticking server-side decorations on them gives
> you two completely different titlebars, and anyone trying to use it
> justifiably thinking the result is an incoherent mess.

There's also millions of Wayland-based products in the market in which
Wayland clients do not render decorations, e.g. in TVs and IVI systems.
Grated, not many of them use much or any of the xdg-* protocols.

Still, compositors do not reject clients which don't render decorations.
The core protocol as-yet doesn't make an attempt to define what a
decoration is, or needs to have in it, on the basis of which it could do
so, either. If it did, the above Wayland systems would suddenly be in
violation. I think we agree these Wayland systems are actually fine and
nice to have.

I'm personally fine with assuming that many or even all of the initial
Wayland contributors assumed CSDs on desktop systems. But I think this
debate over the historic record is obscuring the real needs of this
review, which should be about making sure the protocol under review is
durable, flexible and future-proof, and doesn't introduce unintended
side-effects.

So here's the problem I see: This protocol introduces a definition of
what a decoration is and can do (move, resize, change state). A server
advertising is commits to supporting both, but when a client asks for
SSDs, the server can respond with "use CSDs"

So we have two aspects to this:

a) People are concerned a protocol like this could open the floodgates
to clients which don't implement CSDs at all and indiscriminately ask
servers for SSDs whenever they can.

b) Yet this protocol also allows servers to force clients which prefer
SSDs to force them into CSD mode, and in fact holds them to implementing
CSDs with a number of features (which don't make sense in every system).

In my eyes (b) is pretty clearly more prohibitively costly.

Servers which want to indiscriminately force all clients to provide CSDs
can just not advertize this interface, which is essentially about
letting clients know they have a preferred deco to show.

If they do advertise it, they should allow the client to express a
preference, not abuse the spirit of the protocol - essentially to
properly enable compositors which aim to establish a particular workflow
via decorations (as many existing Wayland compositors do!) - to override
it. Clients which stubbornly refuse to implement CSDs (e.g. mpv) are
unlikely to keep up their end of the bargain anyway, but I think it's
dangerous to run with such a vague definition of "decoration" with
far-reaching implications.

S. Ser said "the CSD mode allows the client to do not draw decorations
at all" in the discussion of v1, but the protocol text certainly doesn't
agree here by defining what a deco is and requiring clients to support
one. I agree with M. Blumenkrantz that the 'mode' thing seems wrong as
it is now. I think the way to go would be:

a) Change the definition of "decoration" to "window controls as deemed
appropriate by the compositor, for example ...". This leaves what's in a
server-side deco and what's in a client-side deco up to servers and
clients, respectively, and allows this protocol to serve more systems.

b) Make the protocol about negotiating between "please deco me as you
see fit" and "I prefer to keep doing my own thing" (which can then still
be "nothing") cases. I don't think any more is needed. I think client
devs are smart enough to understand making this requests implies they
should stop drawing their own title bars, and in the latter case they're
smart enough to know how exactly they want to decorate their window, as
e.g. the GTK+ designers clearly are, and this protocol shouldn't
interfere with them. Certainly the protocol hasn't before felt the need
to teach anybody how to do decorations.

Remember: This isn't about "CSD vs. SSD - which is better?!", it's about
making this one protocol hygienic and good.


Cheers,
Eike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel