You can clone with
Cannot retrieve contributors at this time
On the design of vty It appears to me that there are two kinds of graphicalapplications, regardless of the output form; the synchronous and theasynchronous. Synchronous displays update as changes occur; a goodexample of this type is nethack, with its many newsym() calls embeddedin the logic. Synchronous applications use very little abstractablecode, and in practice all use low level interfaces such as terminfo. Asynchronous screen programs, OTOH, do not have update code withinthe main logic. Instead, they perform output "lazily", only computingit at periodic refresh points. Because "backtracking" is notrendered, asynchronous screen programs use less bandwidth, and can(but usually don't) use less CPU. Asynchronous programs have theirupdate logic centralized in such a way that it can be abstracted as alibrary; this is what both vty and curses are. In the past, vty has had considerable confusion and raceconditions due to the fact that screen resizes can occurasynchronously with respect to output. Vty 3.0 handles this in anvery elegant (IMO) way, by treating resizes as just another inputevent; the size of the picture being output at any time need have norelation to the screen, though of course corruption will result ifthey are different. On a "real" terminal (termcap, not xcurses), output and input canbe completely separated; they can occur concurrently, and do noteffect each other. Because of this we simplify the internal structureby using entirely different mechanisms for input and output. This isalso a great benefit because of the differing characteristics of inputcode (complicated, best table driven, etc) versus output code(performance critical).