Feedback on xdg-shell v5

Sun May 1 17:20:44 UTC 2016

On Friday 29 April 2016, Daniel Stone wrote:
> 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.

Shadows is actually a bit of a red herring here. The real issue is about
whether the compositor should be required to allow a surface to extend
outside the logical window border, for any purpose.

Client side shadows just happens to be one use case for that feature.
Another is to provide an invisible extension of a 1-pixel window border.
And that extension is something you probably want to have regardless
of who draws the shadow.

Fredrik