From: Francisco J Ballesteros <nemo@lsub.org>
To: "9fans@9fans.net" <9fans@9fans.net>
Subject: Re: [9fans] Raw Input Driver
Date: Fri, 20 Mar 2009 15:22:34 +0100 [thread overview]
Message-ID: <2C0788DC-E14D-4C9E-9623-FFA4A01CB761@lsub.org> (raw)
Yes, you split the application. UI
elements are kept at the terminal and
the application at the CPU server. The input event generator knows
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ó:
> 2009/3/20 Charles Forsyth <forsyth@terzarima.net>:
>> in the slow-network situation the thing you're responding to on the
>> display
>> might not be accurate (eg, feedback delayed) which low-level input
>> 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]
next reply other threads:[~2009-03-20 14:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-20 14:22 Francisco J Ballesteros [this message]
2009-03-20 14:32 ` roger peppe
2009-03-20 15:17 ` lucio
-- strict thread matches above, loose matches on Subject: below --
2009-03-20 14:46 Francisco J Ballesteros
2009-03-20 14:35 Francisco J Ballesteros
2009-03-20 14:18 Francisco J Ballesteros
2009-03-20 14:29 ` roger peppe
2009-03-20 7:00 James Tomaschke
2009-03-20 7:07 ` lucio
2009-03-20 7:57 ` James Tomaschke
2009-03-20 9:12 ` erik quanstrom
2009-03-20 11:05 ` Charles Forsyth
2009-03-20 10:54 ` Francisco J Ballesteros
2009-03-20 11:07 ` cinap_lenrek
2009-03-20 11:28 ` roger peppe
2009-03-20 11:39 ` Fco. J. Ballesteros
2009-03-20 12:04 ` erik quanstrom
2009-03-20 11:32 ` erik quanstrom
2009-03-20 12:23 ` Charles Forsyth
2009-03-20 12:16 ` erik quanstrom
2009-03-20 13:03 ` roger peppe
2009-03-20 13:37 ` tlaronde
2009-03-20 14:26 ` roger peppe
2009-03-20 15:02 ` tlaronde
2009-03-20 15:14 ` tlaronde
2009-03-20 12:52 ` maht
2009-03-20 22:23 ` James Tomaschke
2009-03-20 9:13 ` lucio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2C0788DC-E14D-4C9E-9623-FFA4A01CB761@lsub.org \
--to=nemo@lsub.org \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).