From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <2C0788DC-E14D-4C9E-9623-FFA4A01CB761@lsub.org> From: Francisco J Ballesteros To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 5H11) Date: Fri, 20 Mar 2009 15:22:34 +0100 Subject: Re: [9fans] Raw Input Driver Topicbox-Message-UUID: c0ad2aee-ead4-11e9-9d60-3106f5b1d025 Yes, you split the application. UI elements are kept at the terminal and the application at the CPU server. The input event generator knows =20 what's the input, but it runs at the terminal. The only problem is to come up with a widget abstract and generic enough. El 20/03/2009, a las 14:07, rogpeppe@gmail.com escribi=C3=B3: > 2009/3/20 Charles Forsyth : >> in the slow-network situation the thing you're responding to on the =20= >> display >> might not be accurate (eg, feedback delayed) which low-level input =20= >> merging >> won't address. > > true, but that's something that's relatively easy for the user > to adjust to - most actions have an easily perceived visual > result, and if that hasn't happened, i won't initiate my > next action. > > in fact it's a problem with any slow-responding UI, > which is where nemo's point about splitting things up > at a higher level comes in. and that's what (in an extremely > clunky way) the AJAX thing is all about too. > > the problem with choosing a higher level of abstraction is that > the input event generators can't in general be agnostic about > what the mouse/keyboard/whatever are operating on, > so you end up with a smart client or split application, > which lack the same easy composability that you get > from plan 9's remote devices. > > [/mail/box/nemo/msgs/200903/36582]