On 11/21/2014 10:59 AM, Daniel Stone wrote:
And the other is "a useless event that must be sent before the key map changed event".Which you respond to by ceasing _all_ actions related to your current keyboard state, such as cancelling key repeat. So, also not useless.
You are right, it is the "stop repeating keys" event. I didn't think of that. Depending on exactly what keystrokes the server is consuming, it will have to send this, and right away, rather than deferring it to immediately before the enter event, as I was thinking of.
I personally feel it is a mistake to have the client do repeat rather than the compositor, because complexities of timing will not be identical between clients, and because it makes it really difficult to do remote display on a system that does the repeat itself. However this event would still be necessary to cancel "key held down for this long" timeouts.
The way you detect repeat in _core_ X11, is by a stream of paired KeyPress and KeyRelease events. Look it up. Clients rely on this, and conformance relies on it too. I don't know if you've heard of an extension called the X Keyboard Extension (obscure name, I know), but since its inclusion in X11R6.1 in 1996, the XkbSetDetectableAutorepeat function has allowed you to request key repeat be sent as a stream of press-press-press-press-release events, rather than press-release-press-release-press-release. For bonus points, it's even part of the core libX11.so.6 API/ABI. And it works perfectly, and every real toolkit I've seen has made good use of it.
The "old" keyboard api (I think this is what you meant by core) in X sent repeated press events. This was certainly true for IRIX and I believe it was true for the first versions on Linux, because the errors would be obvious if it was different. Forms, XForms, FLTK, Tk and whatever Amazon paint used assumed it worked this way. Prisms and Alias Wavefront did too but they fixed them pretty quick.
You can blame it on the documentation that I never saw XkbSetDetectableAutorepeat. The books we were using for reference predate the change. Because of the enter+exit problem, the toolkit had peek-ahead code for the event stream already, so it was pretty easy to modify this. I suppose if X had done the enter+exit events correctly the peek-ahead code would not have existed and I might have searched harder and found this call.
Also it looks like this function is allowed to fail and return false. This makes it pretty useless as the look-ahead solution has to be implemented anyway as a fallback. Due to the need to minimize code paths to reduce chances of bugs I certainly would not have used this call at all and used the fallback always. But I also suspect this is documentation over-kill and it actually always works: it should not have been defined as returning a failure code. This sort of mistake is what leads to misuse on non-use of documented API.
There are also indications that various bugs make it return true but not work anyway: https://bugs.freedesktop.org/show_bug.cgi?id=22515. Encountering such a bug would also certainly have stopped us using the call.
So I don't know who took the decision to not use a toolkit but instead write their own, to write a toolkit without seemingly looking at any prior art,
You may be unaware of the conditions of things in 1996 but the alternative to writing your own toolkit was to use Motif. I can assure you that the decision was not hard.
Looking at Motif source code is pretty near useless as it is obfuscated beyond belief (it also would not have contained this call for obvious reasons). I based our code on the source for Forms and Tk and GLUT and samples from the web and from reading the blue X11 reference books. GTK was the Gimp Toolkit then and considered part of Gimp (in fact Stallman sent me letters because they were considering using FLTK as the base toolkit, I screwed up on getting the necessary permissions so this did not happen). The K desktop had just appeared, so I guess a rudimentary version of Qt was available, but we never looked at that either.
or to apparently abandon an entire product on the basis that peeking ahead in the event stream was more difficult than five minutes on Google
The product was closed source and they were not maintaining the Unix version. And Google did not exist in 1996.
This is not something which has ever changed in X11, ever. It's not a recent development that someone panicked and changed the X server to do it; it's the same behaviour we've had since 1987, in which time people have worked out how to deal with it. Or most people, anyway.
No I have absolute proof that on Irix and early Linux it did not work this way. The documentation for XkbSetDetectableAutorepeat here http://linux.die.net/man/3/xkbsetdetectableautorepeat seems to say that earlier X servers did not work this way. Perhaps the X11 standard claimed it worked this way (I am not going to read the book to try to find any statement one way or another), but the implementations did not, and the implementations win over the documentation all the time.
Anyway I'm sorry about being mad, but the experience certainly did piss me off at that time, enough that I am still pretty upset about it 20 years later. I had (and still have) great hopes for Wayland, but I am disturbed to see some of the same mistakes from then being repeated.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
