9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Raw Input Driver
Date: Fri, 20 Mar 2009 14:37:04 +0100	[thread overview]
Message-ID: <20090320133704.GA1366@polynum.com> (raw)
In-Reply-To: <df49a7370903200603q57d96528n8caf0183094e026c@mail.gmail.com>

On Fri, Mar 20, 2009 at 01:03:12PM +0000, roger peppe wrote:
>
> 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.

For my own stuff, having to rewrite the 2 dimensions user interface, I
have created a library running on the terminal that keeps the
definitions of the graphical elements drawn with an identifier (3
members) giving to the processing unit (remote) a mean to unambiguously
identifies the antecedent for processing.

This has a lot of advantages. The UI is just a _representation_ of the
data (and in fact of the commands by means of labels/buttons).

All the user wandering on the UI, including selecting things, is done on
the terminal.

Since identifying an element (vectorial elements for KerGIS vectorial
stuff; or cell for a grid etc.) is indeed identifying the representation
of the element, there is no acrobatics trying to convert the
transformation leading to the window, the 1, 2 or 3 pixels between the
hot spot of the pointer and the element (in a GIS, converting the
distance between pixels to a ground distance and searching the element
in ground coordinates), but instead, using the representation for what
it is, so searching the representation near 1, 2 or whatever pixel
tolerance the representation is near (indeed reducing the search to what
is displayed, including ability to mask), and then only sending back the
identifier for the real element to processing.

This fundamental split between the representation, i.e. the UI, and the
processing is the fundamental flaw of the X11 approach which has put the
articulation (the network) on the wrong place: in X11, all the UI
handling, except dispatching window events, is done on the processing
unit (the client in X11 terminology).
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



  reply	other threads:[~2009-03-20 13:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
2009-03-20 14:18 Francisco J Ballesteros
2009-03-20 14:29 ` roger peppe
2009-03-20 14:22 Francisco J Ballesteros
2009-03-20 14:32 ` roger peppe
2009-03-20 15:17 ` lucio
2009-03-20 14:35 Francisco J Ballesteros
2009-03-20 14:46 Francisco J Ballesteros

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=20090320133704.GA1366@polynum.com \
    --to=tlaronde@polynum.com \
    --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).