Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #20087

Re: (E)KEY return values problem

Show all headers | View raw

Zbiggy wrote:

> In comp.lang.forth, Anton Ertl wrote:
> 
>> Yes, there are no guarantees that anything is recognized.  This is
>> pretty much a best-effort thing, and depending on what's between the
>> keyboard and the Forth system, there may be no way to differentiate
>> between <Enter> and <Shift>-<Enter>.
> 
> Do you mean, that in "standalone Forth" implementation, having direct
> access to hardware, it could be simpler?

Or a Forth that has its own (X) window, and doesn't get input through a 
terminal emulator.

>> In this case, xterm maps both <Enter> and
>><Shift>-<Enter> into 13, so Gforth has no way to report the
>> difference.
> 
> Not sure, is it relevant - but my question has been caused by the fact,
> it has been somehow done in TCL/Tk.

Tcl/Tk uses its own window.  What you are doing below is to create a Tk 
widget, and that uses the input events from X, which are certainly "closer 
to the hardware".

> Consider, please, following example:
> 
> #v+
>   package require Tk
>   set keysym "Press a key"
>   pack [label .l -textvariable keysym -padx 2m -pady 1m]
>   bind . <KeyPress-Return> { set keysym "You pressed Enter" }
>   bind . <Control-Return>  { set keysym "You pressed Control-Enter" }
>   bind . <Shift-Return>    { set keysym "You pressed Shift-Enter" }
> #v-
> 
> By trying it you can test, that _somehow_ it's able to recognize the three
> mentioned key-combinations.

If you look closely, you see that it is opening its own X window, and you 
enter the keys *not* in the terminal.

> <Shift>-<PgUp/Dn> indeed may be intercepted by
> text terminal window - but consider the situation, when Forth is operating
> its own graphics window, like the OpenGL examples, for instance.

Yes, in that case, Forth can just as well find out which combination of keys 
are pressed.

> But how much effort and time it all can require to implement - be it
> Gforth or any other Forth-variant - no idea. I was just asking "from
> user's perspective": it would be convenient to have a possibility to check
> for any key(combination), for press- and release- etc. It doesn't really
> have to be part of "core system", since it's not always needed; could be
> kind of "overlay", loaded in case of need.

You are missing the point.  The terminal eats the difference, if it only 
passes on the same byte, we simply can't do anything.  Not all terminals 
behave the same - Konsole gives a different sequence on shift+enter and 
alt+enter, but no difference on ctrl+enter.  I've added the sequences 
Konsole can distinguish to the current development version.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

(E)KEY return values problem Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-25 23:12 +0100
  Re: (E)KEY return values problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-27 15:02 +0000
    Re: (E)KEY return values problem Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-27 20:49 +0100
      Re: (E)KEY return values problem Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 00:27 +0100
        Re: (E)KEY return values problem Rob Sciuk <rob@controlq.com> - 2013-02-28 13:05 -0500
      Re: (E)KEY return values problem anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:04 +0000

csiph-web