2013/9/26 Jason Ekstrand <ja...@jlekstrand.net>: [snip]
>> > I'm not a Wayland developer, so I can't say with confidence. But I think >> > this choice is deferred to the toolkit layer. In this case both >> > behaviors (server of client side decorations) are potentially useful, so >> > the protocol shouldn't *require* one or the other. >> >> I fail to see success on this approach. Today you can run kde >> applications under gnome >> (and vice versa). What about if, with wayland, KDE does server side >> decoration and gnome chooses >> client side decoration, what would a kde application running under >> gnome look like? > > > This question comes up all the time. The simple answer here is that the > negotiation protocol hasn't been written yet. Why hasn't it been written? > Primarily because it hasn't become an issue yet. The only people really > pushing for server-side are the KWin people. However, they are still > working on porting to Qt 5 and QtQuick 2. Once they get to implementing the > Wayland bits and *if* they still want to do server-side decorations at that > point, one of them will probably start working on such a protocol. > >> >> > Though I guess for the >> > issue you mentioned, maybe there should be some protocol to tell the >> > client whether it should draw decorations or not. >> > >> >> Yes, because Blender does not use any toolkit. > > > For now, just draw decorations when not fullscreen. Once a negotiation > protocol gets developed, you can implement it. > Ok. >> >> >> > But this is not the case for the key-replay behavior. There's nothing to >> > be gained by letting different compositors do different things in this >> > case. Both behaviors are fine IMO, so should just require whatever >> > Weston does currently. >> >> I hope compositors agree on following the same path for "undefined >> behaviors", >> otherwise toolkits and applications will have a hard time to come. > > > Looking at weston's input.c, I am not seeing any evidence that it sends any > key events due to an enter. It does resend the modifiers, but that's > different. It doesn't make sense to me that you would send the currently > depressed keys as an array and then send them again one-at-a-time. > I did a quick test, and indeed keys are not resent. However, I could not test modifiers because when I hold a modifier, I couldn't switch windows. I just arrived from an work trip and haven't time to check weston code yet. >> >> > >> >> >> >> > So if you see what happens exactly, it'd be nice if you open a bug, >> >> > or >> >> > post back, or send a patch :) >> >> >> >> Do you mean about the behavior when we have more than one keyboard >> >> attached to a seat? >> > >> > No, that should work seamlessly. I meant the replay of the key press >> > events (after you manage to implement your stuff in a real world >> > application like Blender). >> > >> >> Not a problem, I will do that. > > > In theory, a client should not be able to notice that more than one keyboard > is plugged into a seat. I'm not sure that that is correctly implemented in > weston right now, but I seem to remember it being the case. A better person > to ask about that would be Daniel Stone. > > Thanks, > --Jason Ekstrand -- Best Regards, Wander Lairson Costa _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel