Hi, On 29 April 2016 at 10:37, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 29 Apr 2016 15:31:28 +0800 > Jonas Ådahl <jad...@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 <jad...@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
