Date: Wed, 04 Dec 1996 04:43:53 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: fenner@parc.xerox.com, ports@freebsd.org Subject: Re: Ports INDEX browser update Message-ID: <2773.849703433@time.cdrom.com> In-Reply-To: Your message of "Wed, 04 Dec 1996 22:31:02 %2B1030." <199612041201.WAA16510@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> (Mike quickly wipes his hands and shoves the rest of the chips out of
> sight; "me? grease? never!" 8)
:-)
> Oooh, after I got caught up in a C vs. Forth flamewar in
> comp.arch.embedded, do I want my name anywhere near a stack-based
> language? 8) Still, it sounds like ripping the interpreter and
> the script out and handling the canvas events with a text widget
> might just be the way to go. How fine is the event granularity?
> (single characters only, or are there bigger primitives?)
You don't need to really rip the interpreter out - it's passive if
it's got no work to do. The event granularity is right down to a
single character - each character percolates through a TRIE structure
built from reading the interpreter description (if there is one) and
either falls out the end, being then passed to any other registered
input handlers in turn, or is eaten by one of the handlers.
Basically there's a term "widget" which doesn't actually occupy any
screen real-estate or create windows, it just handles the PTY
allocation and UTMP entry insertion (if enabled), then reading in a
parser description (if any) and setting up the default I/O handlers as
appropriate. You can also add your own "parsers" using the
XpNinParser / XpNoutParser resources - our fancy name for a callback
handler which gets passed a structure containing the I/O buffer area
and some pointers into it describing what's been read so far and is
currently waiting for someone to do something with the data.
Then there's a "termCanvas" widget which essentially handles all the
actual screen/mouse/keyboard I/O and can take requests from a term
widget (or anything else, really) to paint stuff on the screen.
The client known as "emu" is just a small program which creates one
term widget, one termCanvas widget and then sticks them both into a
shell widget. It also implements the menu and scrollbar behavior,
using hooks which the termCanvas makes available for accepting
external scrolling requests.
And that's probably more than anyone ever wanted to know about emu,
but perhaps I can be forgiven for being a somewhat proud pappy on this
one. :-) It's actually one of the cleaner terminal emulators around,
which probably isn't saying much, but we always wanted to do xterm
"right" and I think emu is probably the only time someone tried to
modularize the problem to this extent. Practically nothing, from the
menus to the scrollbars to the very terminal emulation, is hardcoded -
it's all a resource string somewhere.
> Mike types 'emu' in the PIB search dialog, discards 'cpmemu' as probably
> not being the one, hits 'emu-1.3.1'. Hmm. "Maintainer : me@FreeBSD.org".
> A search for "me@" gets me xemacs, seyon, emu, fvwm and mmv...
Yeah, Michael's a pretty motivated ports maintainer. My pattern is
more one of "think about a problem, implement a proof of concept
implementation which proves to my satisfaction that it can be done,
get bored and go onto something else." :-) Perhaps I should have
been a mathematician.
> Ah well, humour is subjective 8) Still, sounds like the way to go,
> even though it's going to be a bit of a diversion. Speaking of widgets
> and diversions, here's one that wasted me an hour tonight :
>
> > wish4.1
> % listbox .foo
> % pack .foo
> % bind .foo <1> {puts "click"}
> % bind .foo <Up> {puts "up"}
>
> Button-1 in the listbox, it says "click". Hit Up in the listbox, does
> nada. I got down to this trying to work out why the default class
> bindings for listboxes and scrollbars just _don't_ work. Is this an R6
> thing? It's as annoying as all snot. (No, I do _not_ have NumLock on!)
Hmmm. Ask yourself another question: How do keyboard bindings work
at all? :-)
I'm buggered if I can get *any* sort of keybinding to work. Now
you've got *me* staring at my TCL book in confusion. Thanks heaps,
dude. :-)
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2773.849703433>