On Tue, 30 Apr 2013 08:30:52 -0400 Todd Showalter <t...@electronjump.com> wrote:
> On 2013-04-30, at 3:29 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > > What an application could actually do when it receives a home button > > press via the special path is an important question. Since Wayland > > does not allow random clients to just jump in, you need to > > specifically think how to enable a desired response. In that > > respect, having a third party program handling the home button is > > very problematic, since you probably want something to happen on > > screen. > > Perhaps this is a place for window manager functionality; if > there is a separate home button message, we could allow a window to > request to filter home button messages for another window. So the > hypothetical steam behaviour would be to request the home button > events for any games it spawns. Hello Todd, unfortunately that is not how Wayland works at all. All clients are isolated from the start, regardless how they are spawned. The idea might be ok, but concepts and protocol design will be very different. > The advantage of the separate event in that case would be > isolating the home button event, since I presume that nobody wants > the security nightmare of arbitrary event filtering. The home button > is a system meta event, so it's reasonable to have other processes > watching it. > > I suppose it could be a broadcast event... As far as I understand, what you want is what I described with the home_interface, with the exception that there is no filtering based on the currently focused client. The home_interface is just something an unrelated client could subscribe to, and then it would get the home button events. The third party program handling the home button is a really problematic case, and this still does not solve the question of what the client receiving the home button event can actually do. Normally Wayland does not allow clients to e.g. randomly raise themselves to top, not to mention do anything to other client's windows, since they cannot even reference anything from another client. Getting the event is useless, if you cannot react. Could we instead design a behaviour for the home button, which the display server (which is also the window manager) would implement itself, and which would also satisfy the Steam use case? For example: the home button minimizes the currently focused fullscreen window. Or, maybe it brings up the task switcher, if the task switcher can be controlled by a gamepad. With the task switcher, the user could select the Steam client, or another concurrent game, or... I just believe, that sending "the home button was pressed" to all clients as a "system meta event" is not right. Instead, the server would intercept it, and send specific events to clients' windows, like un-fullscreen, un-maximize, minimize, raise, lower, go to sleep, etc. that all depend on the current shell (i.e. a desktop vs. a game console GUI vs. a phone vs. a TV vs. ...). If we solve this in the server, we don't have to note it in the gamepad protocol at all. In fact, I think we can just postpone this problem, since the wl_gamepad should be irrelevant to how a home button is handled. wl_gamepad can perfectly well relay the home button events to the game, anyway. The question is when and if that happens, and that does not need to be written down in the specification. Doesn't really help that I've never used Steam, nor know what Big Picture is. But I do have a PS3 at home! :-) Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel