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. -Rick- _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel