Date: Thu, 5 Dec 1996 11:11:43 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, fenner@parc.xerox.com, ports@freebsd.org Subject: Re: Ports INDEX browser update Message-ID: <199612050041.LAA18501@genesis.atrad.adelaide.edu.au> In-Reply-To: <2773.849703433@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 4, 96 04:43:53 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying: > > 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. No, I meant "rip them out and use them", not "rip them out and throw them in the slops bucket under the table". (They would probably react badly with the leftover garlic sauce from my lunch 8) The reason I asked about the event granularity was just from the POV of performance; if we're handling events character-by-character we're going to have to bind rather more tightly to the text widget. > 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. Ok; the 64-dollar question : could we replace the termCanvas widget with the Tcl text widget? If this can be done at runtime, then we win with a 'term' (rather than 'text') widget that knows how to execute programs and disply their output. > Yeah, Michael's a pretty motivated ports maintainer. My pattern is *ouch* 8) Ok, ok, what do I have to fix? > get bored and go onto something else." :-) Perhaps I should have > been a mathematician. Nooo! (and you don't drink enough, or look any good in khakhi shorts and sandals 8) > > 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? :-) Dunno. They work for Entry widgets 8( > 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. :-) Maybe I should just post to comp.lang.tcl and reveal my Tk weeniehood. 8( > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612050041.LAA18501>