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

Groups > comp.lang.forth > #20030 > unrolled thread

(E)KEY return values problem

Back to article view | Back to comp.lang.forth

Contents

  (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

#20030 — (E)KEY return values problem

Not sure: is it proper behaviour of EKEY, that it doesn't recognize "just
any" key-combination?

I would to have available various key-combinations - obvious in many
situations - but using KEY/EKEY e.g. I get "13" for both <Enter> and
<Shift>-<Enter> (or for <Control>-<Enter>) - a little test in Gforth. On the
other hand: <Shift>-<PgUp> and <Shift>-<PgDn> are ignored by KEY / EKEY.

Fortunately, EKEY seems to allow recognition of many key-combinations - like
<Shift>-<Home>, <Control>-<Home> (the result is different) - but shouldn't
it work for just all of them? Well, maybe not necessarily e.g. 3 letter-keys
pressed at the same time - but at least all <key>-<key-modifier> combinations
("key-modifiers": shift, alt, windows-key, control - left and right ones
recognized separately)?
-- 
It's us, the scobs.

[toc] | [next] | [standalone]

#20062

Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
>Not sure: is it proper behaviour of EKEY, that it doesn't recognize "just
>any" key-combination?
>
>I would to have available various key-combinations - obvious in many
>situations - but using KEY/EKEY e.g. I get "13" for both <Enter> and
><Shift>-<Enter> (or for <Control>-<Enter>) - a little test in Gforth.

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

E.g., I just tested this in a setup where the keys are pressed on the
keyboard (which has its own CPU and eventually produces keycodes), is
processed by the X Server on the X terminal (possibly it had to go
through the Linux kernel on the X terminal before), which produces
KeyPress and KeyRelease events and translates keycodes into keysyms,
then the events get sent over to the xterm terminal emulator running
on the server that runs Gforth, which translates the X stuff into
stuff a vt100-like terminal would produce, and this is finally what
Gforth sees.  In this case, xterm maps both <Enter> and
<Shift>-<Enter> into 13, so Gforth has no way to report the
difference.

You might write your own terminal emulator (or maybe reconfigure
xterm) to be more discerning, but that's not always practical (in the
extreme, what if a real terminal is connected that does not report the
difference?), so prepare your programs not to rely on being able to
recognize the difference.

> On the
>other hand: <Shift>-<PgUp> and <Shift>-<PgDn> are ignored by KEY / EKEY.

On my xterm these combinations are caught by the xterm and not
forwarded to the application; they are interpreted as scrolling
commands.

>Fortunately, EKEY seems to allow recognition of many key-combinations - like
><Shift>-<Home>, <Control>-<Home> (the result is different) - but shouldn't
>it work for just all of them? Well, maybe not necessarily e.g. 3 letter-keys
>pressed at the same time - but at least all <key>-<key-modifier> combinations
>("key-modifiers": shift, alt, windows-key, control - left and right ones
>recognized separately)?

Sure, that would be nice, but it's not realistic.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#20071

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?

> E.g., I just tested this in a setup where the keys are pressed on the
> keyboard (which has its own CPU and eventually produces keycodes), is
> processed by the X Server on the X terminal (possibly it had to go
> through the Linux kernel on the X terminal before), which produces
> KeyPress and KeyRelease events and translates keycodes into keysyms,
> then the events get sent over to the xterm terminal emulator running
> on the server that runs Gforth, which translates the X stuff into
> stuff a vt100-like terminal would produce, and this is finally what
> Gforth sees.  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. 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. <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.

You can add two more lines, to find out, they are recognized, anyway:

#v+
  bind . <Shift-Next>  { set keysym "You pressed Shift-PgDn" }
  bind . <Shift-Prior> { set keysym "You pressed Shift-PgUp" }
#v-

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.
-- 
It's us, the scobs.

[toc] | [prev] | [next] | [standalone]

#20087

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/

[toc] | [prev] | [next] | [standalone]

#20107

This will report key sequences (at least in MiniForth) until you hit an x 
(ascii 120) to exit.  If your keypress results in multi-key escape 
sequences, the nexsted loop will report them and then issue a cr.

: x begin key dup 120 != while . begin ?key while key . repeat cr repeat ;

For instance, function key F5 - F8 report the following sequences when 
the f-lock is enabled ...

27 91 49 53 126
27 91 49 55 126
27 91 49 56 126
27 91 49 57 126

HTH,
Rob.

[toc] | [prev] | [next] | [standalone]

#20178

Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
>Do you mean, that in "standalone Forth" implementation, having direct access
>to hardware, it could be simpler?

Yes.

>Not sure, is it relevant - but my question has been caused by the fact,
>it has been somehow done in TCL/Tk.

TK is an X toolkit, so it's certainly possible to see things through
TK that you don't see through xterm.  Its possible to write a Forth
that talks to X (e.g. xbigforth) instead of to a terminal (emulator),
but that would restrict Gforth to platforms supporting X, for not that
much benefit.  Of course, you could use the C interface to talk to
Xlib or one of the toolkit libraries that work with X (e.g., Tk).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web