On Wed, May 08, 2013 at 11:46:43AM +0000, Rick Yorgason wrote: > Rick Yorgason <rick@...> writes: > > > Having the two controllers paired doesn't solve 3. There are a lot of UI > > > problems with having two pointers running around the screen that share a > > > focus. Let's say they're one of those crazy users that like sloppy- > > > focus. What happens when the two cursors are on different windows? Does > > > the primary cursor over-ride? Does the secondary cursor work in windows > > > that aren't focused? Even if you have click-to-focus, you still have > > > problems with the two cursors fighting. What happens if they both try to > > > do a drag-and-drop? The only solution to this is probably to make the > > > secondary pointer inert in windows that aren't focussed. That said, I'm > > > not sure if that 100% fixes it either. > > > > I was thinking that a desktop environment would probably only have one > > cursor. In other words, if any wl_seats are sharing focus, most apps would > > treat them as aggregate, and it would only be more specialized apps (like > > games) that might want to separate them. > > In thinking more about this some more, I don't even think these seats need > to be aggregated. A second-class wl_seat would just mean "This seat is > intended to be used at the application level rather than the compositor > level, and it will send enter/leave events to the same surfaces as its > parent." > > In other words, if you move the mouse attached to a second-class wl_seat, > the compositor completely ignores that motion. > > Now, when you read what I wrote about how enter/leave events get propagated > to second-class wl_seats, you probably thought "Wait, enter/leave events are > produced by wl_pointer, wl_keyboard, and maybe wl_gamepad. Are you > suggesting *all* of those get propagated?" > > Well, I don't think it makes sense to propagate wl_pointer::enter/leave, and > this leads me to what I believe is an unfortunate design choice in the > current protocol, which is that wl_keyboard::enter/leave doesn't make much > sense. It should really be wl_seat::enter/leave. > > wl_pointer::enter/leave makes sense because pointers are special. They can > freely move outside of surfaces, and can affect things in unfocused > applications. But the keyboard focus is pretty much identical to the > application focus: in a typical compositor, when an application gets > keyboard focus, that application's title bar will light up. > > Currently it would make perfect sense for wl_gamepad to use wl_keyboard's > focus except... what do you do if there is no keyboard? This would have been > an easier problem to solve if we could just say that wl_keyboard and > wl_gamepad both use wl_seat's focus.
if you have more than one application open, you may want the keyboard focus in a different window than gamepad focus. think of 'taking notes while playing a game' from what I understand nothing currently stops the compositor from setting the gamepad focus to the same surface as the keyboard focus. encoding that in the protocol however is not a good idea. Cheers, Peter _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
