9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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]



             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).