Feedback on xdg-shell v5

[Daniel Stone]

Hi,

On 29 April 2016 at 10:37, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 29 Apr 2016 15:31:28 +0800
> Jonas Ådahl <jadahl at gmail.com> wrote:
>> On Thu, Apr 28, 2016 at 02:08:07PM +0300, Pekka Paalanen wrote:
>> > On Thu, 28 Apr 2016 17:36:58 +0800
>> > Jonas Ådahl <jadahl at gmail.com> wrote:
>> > > Because you don't ping a surface, you ping the client. It's the client
>> > > that may be inresponsive, and if the client is in responsive, it's safe
>> > > to assume all its surfaces are as well.
>> >
>> > I was going to plain agree and say, that all events to a client come
>> > through the same connection (wl_display), and it does not make sense to
>> > have a series of ping events on different objects when they could just
>> > be collapsed into one equivalent event.
>> >
>> > But then I thought about multiple client-side event queues. If a client
>> > has multiple queues, and windows on different queues, it could be
>> > possible that only some queues get stuck while others are serviced.
>> > With per-surface pings, the compositor should then "shade out" only the
>> > windows where the queue is actually stuck.
>> >
>> > Would it be worth it?
>>
>> I doubt it. What would you do? It's not like you can disconnect half of
>> a client.
>
> Wasn't it more about marking unresponsive surfaces and providing UI
> aids for dealing with them, e.g. moving the window out of the way?
>
> If you hover over the "kill this app" option, the compositor could e.g.
> color all the surfaces that would go, not just the ones unresponsive.

What does 'kill this app' do, if not zap the wl_client? How do you
selectively kill surfaces, or client-side event queues?

There is the argument that one part of the app is active and the other
is dead, but I don't think it's possibly to usefully separate those
out, and also surely you can build an intra-client ping setup as well,
so deadlocked threads result in no pong.

>> > Huh, I always wondered what practical use shadows might have apart
>> > from visual appearance. I can also see how using shadows for any user
>> > interaction while they are outside of the defined window geometry is
>> > going to fail.
>>
>> Why would it fail? It has worked perfectly fine so far. With SSD, this
>> is how things are done as well on X11 - part of the shadow around the
>> window will be available for triggering window resizing. Think of the
>> shadow as part of the window border, instead of just shadow.
>
> Is the shadow a part of window decorations but outside of the
> window geometry?
>
> When you then snap another window beside the first one, you'd snap
> based on the window geometry, right? Then you lose the shadow region of
> the window that happens to be below. The shadow of the window on top
> will extend into and clobber the window below. Or would snap leave a
> shadowy region between the windows? Or do you use window geometry to
> cull the shadow of both windows, in which case you lose it from both on
> the touching egdes?
>
> But yeah, I have no idea how that works. I've never had nor wished for
> shadows, so I can't really understand the big deal about them. I'm
> happy having just nice decorations which are accounted into the window
> geometry.

The shadows are decoration.

>> > > I'd much rather see a solid default which does things "the Wayland way"
>> > > (as described above) that will work reasonably well in a minimalistic
>> > > default weston reference shell, and doesn't imply that the compositor
>> > > should go into effect drawing territory, and I don't think the hybrid
>> > > solution is this.
>> >
>> > I'm not sure there is a "the Wayland way" really for shadows. We did
>> > start with clients just drawing their own shadow as part of the
>> > surface. I assumed that was only because it was very easy to do for a
>> > little bit of eye-candy. We'd have to ask Kristian if there was more
>> > though behind it than that.
>>
>> With "the Wayland way" I really only meant that the compositor, when
>> possible, doesn't spend time rendering eye candy and/or user interfaces.
>
> Sure. This brings us to my suggestion of the default by the Wayland
> way: no shadows at all. No implementation is simpler implementation.

Unfortunately the reality, as shipped in quite a few places by
toytoolkit, GTK+ and others, is that clients render shadows. Any
proposal which doesn't take into account the current on-the-ground
reality (that this has been happening for years) doesn't seem too
serious to me.

>> > I would hope you can find a way to extract shadows as a separate part
>> > of the protocol where the compositor and client can agree on who draws
>> > it, if at all. I'm sure you'll have exactly the same issue with window
>> > decorations in general, especially considering if shadows are actually
>> > functional rather than just visual.
>>
>> We do indeed need a way to do these negotiations. But we also need to
>> have a sane, workable fallback as well.

I fall very, very, firmly on the client-side decoration side of
things, for many reasons: less complexity in the compositor, more
predictable and responsive compositor repaint cycles, not being stuck
in resize cases where the client draw provokes a panicked last-minute
compositor relayout and draw, avoiding the need for things like
internationalisation/bidi, etc etc etc. But I get why people like
server-side decorations, even if I don't for one second believe that
the complexity tradeoff is worth it.

But shadows? What do we possibly gain in adding a protocol - with code
to handle each possible combination - to negotiate _shadows_?

>> > IMHO, the default minimalistic way is no shadows at all for anything.
>> > That would be the Wayland way if any, keeping it simple by default and
>> > everyone equally grumpy ;-). If the compositor then supports shadows on
>> > either server or client side, or both sides by client decision, that
>> > would be something more.
>
> Right, so, first sorry for butting in with the above comment. I'm not a
> desktop designer and I don't know how desktop works.
>
> I just couldn't stand by and watch how this discussion seemed to
> deadlock at the start where both sides just defend their own
> needs and cannot propose a middle-ground. So I'm here to make you both
> sad. ;-)

Well, if the compromise/middle-ground option (two people want one
pony; cut the pony in half and give one part to both) is worse than
either alternative ...

> In IRC you asked what do I propose then. Ok, here's hand-waving. There
> are four different cases:
>
> 1) No-one draws any shadows. This is the default. Clients know to not
> rely on shadows, so they will e.g. draw thicker decorations if they
> intend them to be used as handles etc.

This is not, right now, the default, and will continue to not be the
default for these clients.

> With this setup, if you have a client that does not use any of those
> global shadow interfaces, then it will get only server-side shadows if
> the server supports it. Such a client would not draw its own shadows
> and not rely on shadows being there to be usable.

There is a lot of complexity in this, and I just don't see what the gain is.

Cheers,
Daniel