Comment by mike_hearn
3 years ago
Yes, my point is that an alternative OS design could serialize keystrokes such that a keypress has to be handled (including focus changes) before the next keys are delivered, allowing you to type ahead without keypresses going to the wrong place or depending on the vagaries of timing. It might require a different approach to UI API and design, though.
That's not really practical with a preemptive multitasking OS. There's no guarantee (without real-time scheduling) any process will have uninterrupted time on the CPU(s).
According to an external wall clock the keypress events happen at seconds 1, 2, and 3. The first press triggers a window to appear (menu panels are a type of window). It takes 0.5s to instantiate and register to receive keypress events from the shell. Wall clock time is 1.5s. Nice.
The second window (menu panel) receives a keypress event at wall clock 2s which opens a third panel. That panel because it has more complicated drawing and page faulted so had to fetch a page from disk swap unfortunately took 1.2s to register for focus. A keypress triggered at wall clock time of 3s. Our third panel though didn't register focus until wall clock 3.2s. That keypress went to panel 2 because that had focus when the keypress event triggered. All times greatly exaggerated.
The shell needs to add events to processes' event queues but it can't just arbitrarily add them to every process. It also can't know any individual window wants events until the process tells it so. Unlike mouse events a keypress event doesn't have coordinates so a process can't really figure out the intended target of an event.
A model that prevents preemption means your back to the Win16 cooperative multitasking. A process can't be interrupted until it gives up the CPU willingly. That however means background processes can't do work while a foreground process holds the CPU. If you make just your shell and GUI apps cooperative the responsiveness of the system will end up awful.
That's the issue you'd face with today's operating systems and UI designs, yes, but I'm talking about a hypothetical new OS design.
In such an OS the APIs would allow you to atomically transfer focus as part of other operations, for example, starting a new program or opening a new window could simply transfer focus atomically to the pending new program/window such that the OS buffers keystrokes until the recipient is ready to receive them. Also, taking focus would require you to advertise what keys you're willing to receive, allowing a focus cascade such that there's never any situation in which keystrokes get delivered to a UI that isn't able to do anything with them. At the top level of the shell there'd be a kind of global command line or palette that is the default receiver of all other unhandled keystrokes. Because focus transfer is always deterministic under this scheme, people can learn where keystrokes will go without timing playing a part.
That alternative OS is called... 16-bit Windows.