ENTER and RETURN

[FourthWorld]

I don't think the amount of use-cases people asked about in the last 35 years is a good measure of whether or not some syntax merits discussion, there could for example have been people with a desire to do some keyboard input tracking and didn't find an easy, sensible way to do it (using key code-numbers isn't sensible in an xTalk way, IMO) and so gave up.

Anything is possible. The imagination is punished limitless. Observing the number of requests is one method of quantification. Open to better ones.

But if it's a personal interest, no argument there. Your project, your time; spend it as you find enjoyable.

Yes, recompiling the OXT Mac engine as an Apple M-series native binary is still something OXT needs.
I was thinking maybe this could be crowd-funded and outsourced.

Yes, outsourcing is what I've been pursuing.

Which thread can I point interested devs to so they can understand the scope of the issue?

[OpenXTalkPaul]

But if it's a personal interest, no argument there. Your project, your time; spend it as you find enjoyable.

Well yeah, fine control over keyboard input it is part of my own interest, but I can't imagine that Richmond and I are the only ones with that interest in that. Keyboard input seems more of a general use thing for app dev to me.

Yes, outsourcing is what I've been pursuing.

Which thread can I point interested devs to so they can understand the scope of the issue?

I don't think there's is any recent threads about crowd-funding (maybe there was in the beginning?). There is a subform I made wayback that was meant for discussing issues/tips, 'Compiling The Engine From Source' but there has never been much activity there. Anyway, feel free to make a new thread for discussing crowd-funding ideas.

One thing I'd tell devs that might want to take on the task is that I think the size of the repos make the problem look maybe bigger than it is(?) I've been able to compile some externals and libraries myself. I'm mostly concerned with getting the core IDE executable binary compiled. I still don't own an M-series CPU mac myself so I don't even have the hardware to test that on.

[tperry2x]

I was banging on about this for a good while, but I decided to mention it no more.
The last post I made was here.

Also, from the 'bugs to fix' page:

(Engine does not support ARM macs (only via Rosetta 2, but this will be dropped when Apple moves purely over to ARM - longer-term consideration). *I'm not mentioning this any more

[richmond62]

Here is something worth considering . . .

I put out a 'begging letter' for money to buy a 'New-Fer-Me' iMac and the donations exceeded the sum requested within a week.
-

Appeal.png (160.65 KiB) Viewed 2838 times

-
No offers of T-shirts, just a set of 'Thank Yous'.

There are a lot of very generous and helpful people around, and I would not doubt for a moment that if:

1. You could find someone prepared to 'twiddle' a Mac ARM processor engine for OXT.

2. They could name a price that was not 'off the blood pressure gauge'.

We could find people who would 'do their bit' to reach that sum inwith a sensible amount of time.

[richmond62]

that number is one

The person who wrote that had best consider a few things:

1. Hans Anderson's story about The Emperor's New Clothes.

2. If some people had NOT asked questions or requested things that had not been requested before we might very well be sitting around in caves wondering where all the Mammoths had gone and why (because some 'twonk' hadn't had ideas such as animal husbandry, and vegetable cultivation) we were starving to death.

[tperry2x]

On the Haiku website they have this:
I wonder about adding a small progress bar (horizontally though) to the top of this forum, showing funding status. When clicked, it'll take you to a funding goals page - showing what we require for the OXT project?

Sound like a good idea?

Screenshot_20240621-161125_Opera.jpg (173.5 KiB) Viewed 2830 times

[tperry2x]

I was thinking like this:

quite-easy-to-do.png (108.75 KiB) Viewed 2823 times

Which you can add in CSS:

Code: Select all

#start_here {
  content: "";
  display: block;
  width: 20%;
  margin: 1em auto 0;
  border-bottom: solid;
  border-color: green;
}
#start_here:before {
  margin-left: 20px;
  content: "Funding goal: 20%";
}

In your file:
https://openxtalk.org/forum/styles/Abso ... /links.css

[FourthWorld]

Well yeah, fine control over keyboard input it is part of my own interest, but I can't imagine that Richmond and I are the only ones with that interest in that. Keyboard input seems more of a general use thing for app dev to me.

Keyboard entry is generally useful.

Using one specific key in a highly specific way the runs counter to half a century of ingrained usage patterns reinforced by many GUI toolkits is less general.

True, we need not wait until others express a need to act on it. Much of open source, and innovation in general, comes from scratching one's own itch.

What are you working on that it made more difficult by the current Enter key handling?

Of course if the only one doing the work simply wants to do the work, it doesn't need to be justified to anyone else.

I was just hoping to learn where this is needed. But no one's asking me to implement it, so my question can be safely ignored.

Yes, outsourcing is what I've been pursuing.

Which thread can I point interested devs to so they can understand the scope of the issue?

I don't think there's is any recent threads about crowd-funding

I'm familiar with crowd sourcing.

My question was in search of a task definition so a potential bounty hunter could understand the scope of what's needed.

I believe it has do to with missing required inclusions, but I wasn't able to provide the prospective bounty hunter with details on those or what efforts have already been attempted so we can avoid replicating those efforts.

Does this project maintain a bug DB to keep this sort of info centralized for moments like this?

Whether at GitHub or these forums or Bugzilla or something else, any one-stop for tracking outstanding issues and logging relevant details for recipes and work-to-date would simplify work for contributors.

[tperry2x]

Does this project maintain a bug DB to keep this sort of info centralized for moments like this?
Whether at GitHub or these forums or Bugzilla or something else, any one-stop for tracking outstanding issues and logging relevant details for recipes and work-to-date would simplify work for contributors.

Once again, link here
Known bug tracker (ones I care about)

[FourthWorld]

Once again, link here
Known bug tracker (ones I care about)

Thank you. Bookmarked.

[OpenXTalkPaul]

Using one specific key in a highly specific way the runs counter to half a century of ingrained usage patterns reinforced by many GUI toolkits is less general.

True, we need not wait until others express a need to act on it. Much of open source, and innovation in general, comes from scratching one's own itch.

What are you working on that it made more difficult by the current Enter key handling?

Of course if the only one doing the work simply wants to do the work, it doesn't need to be justified to anyone else.

I was just hoping to learn where this is needed. But no one's asking me to implement it, so my question can be safely ignored.

I just don't think that wanting an easy way to check the state of a specific key on a keyboard "runs counter to half a century of ingrained usage patterns". These key codes come from only one usage pattern AFAICT and that is an Xwin/Unix pattern from 35+ years ago.

OK lets look at my particular needs / use cases:
What if my script is in the middle of performing some action that was triggered by the returnKey and I need to check if it's still down or if it has been released since the action was triggered? Perhaps the script needs to flushEvents() so that key-Repeats are canceled out so that they don't trigger the action again while it's already running causing the same action to repeat 20 or 50 times. I've had to do this sort of thing a bunch, thank goodness there is flushEvents(). The engine does provide ways to do this stuff already so surely there must have been other users who needed this level of control.

What I was working on somewhat recently was an OnScreenKeyboard Widget, which I wanted to have auto-highlight the virtual keys of the virtual keyboard based on key messages that are already generated by the Engine, which would then be forwarded along with the key parameter to the widget (I've included with the Widget pre-made defaultScripts for all of the common keyboard message handlers) using syntax like: 'do pArbitraryString in widget 'OnscreenKeyboard' . One issue I ran into in doing this was that 'on optionKeyDown' doesn't get sent until an additional non-modifier key is also pressed. The optionKey being 'down' with no other being keys being down can only be checked with optionKey() = 'down' or its key code-number being among the items of 'the keysDown'.

Honestly, I'm not sure why Richmond was looking for a similar function version for 'enterKey()' and 'returnKey()'. You can use either keyDown/rawKeyDown or the keysDown to check their state. Those aren't special modifier keys, they're only keys for two 'non-printable' characters. If you need to check those keys frequently I would use a handler like the two that I posted.

I also don't know why Richmond thought that this doesn't work on macOS, I've never had a problem doing checking these keys on macOS.

[OpenXTalkPaul]

Using one specific key in a highly specific way the runs counter to half a century of ingrained usage patterns reinforced by many GUI toolkits is less general.

True, we need not wait until others express a need to act on it. Much of open source, and innovation in general, comes from scratching one's own itch.

What are you working on that it made more difficult by the current Enter key handling?

Of course if the only one doing the work simply wants to do the work, it doesn't need to be justified to anyone else.

I was just hoping to learn where this is needed. But no one's asking me to implement it, so my question can be safely ignored.

I just don't think that wanting an easy way to check the state of a specific key on a keyboard "runs counter to half a century of ingrained usage patterns". These key codes come from only one usage pattern AFAICT and that is Xwin on Unix, which is where I tracked these specific 'rawKey' numbers down to in a .h header file from like 40+ years ago.

OK lets look at my particular needs / use cases:
What if my script is in the middle of performing some action that was triggered by the returnKey and I need to check if it's still down or if it has been released since the action was triggered? Perhaps the script needs to flushEvents() so that key-Repeats are canceled out so that they don't trigger the action again while it's already running causing the same action to repeat 20 or 50 times. I've had to do this sort of thing a bunch, thank goodness there is flushEvents(). The engine does provide ways to do this stuff already so surely there must have been other users who needed this level of control.

What I was working on somewhat recently was an OnScreenKeyboard Widget, which I wanted to have auto-highlight the virtual keys of the virtual keyboard based on key messages that are already generated by the Engine, which would then be forwarded along with the key parameter to the widget (I've included with the Widget pre-made defaultScripts for all of the common keyboard message handlers) using syntax like: 'do pArbitraryString in widget 'OnscreenKeyboard' . One issue I ran into in doing this was that 'on optionKeyDown' doesn't get sent until an additional non-modifier key is also pressed. The optionKey being 'down' with no other being keys being down can only be checked with optionKey() = 'down' or its key code-number being among the items of 'the keysDown'.

Honestly, I'm not sure why Richmond was looking for a similar function version for 'enterKey()' and 'returnKey()'. You can use either keyDown/rawKeyDown or the keysDown to check their state. Those aren't special modifier keys, they're only keys for two 'non-printable' characters. If you need to check those keys frequently I would use a handler like the two that I posted.

I also don't know why Richmond thought that this doesn't work on macOS, I've never had a problem doing checking these keys on macOS.

[OpenXTalkPaul]

As further proof that easy, very fine-control level keyboard polling must be a desired feature of the xT interpreter, in later engine versions additional 'event' forms of the modifier checking functions were introduced, eventOptionKey(), eventControlKey(), etc. which provide the state the key was in when the handler it's used in began its execution, which may be different from the state the key is in by the time the engine gets to the script line that these functions are called from, which could be hundreds of milliseconds later.

[FourthWorld]

I've had to do this sort of thing a bunch, thank goodness there is flushEvents(). The engine does provide ways to do this stuff already...

Thank you. Good example, good solution.

[tperry2x]

I never found out if it was the keyboard at fault, the OS, or something else.
I'd just like to know, if Richmond could find out - what was stopping the returnkey and enterkey messages from working as expected. Just out of curiosity more than anything, but also to know if it's another bug with certain keyboards we need to be mindful of.

[richmond62]

the returnkey and enterkey messages from working as expected

Hmm: they have always worked like that with MacOS.

A rawKeyDown returns 65421 for ENTER, and 65293 for RETURN on MacOS.

The 'problem' is the inconsistency between what are termed the 'action' keys [ENTER, RETURN] and the 'modifier' keys [COMMAND, CONTROL, ALT/OPT, SHIFT].

one can write this sort of code with a modifier key:

Code: Select all

if shiftKey() is down then
-- do something
end if

BUT one cannot do that for either the ENTER or the RETURN key, so checking if either of those keys is pressed is rather difficult.

One cannot poll the rawKeysDown, only keysDown, and as the ENTER and the RETURN key ONLY return a rawKey signal . . .

My main 'beef' is that xTalk is inconsistent here (and with arrowKey).

[richmond62]

Screenshot 2024-06-22 at 13.27.32.png (124.41 KiB) Viewed 2726 times

-
Detecting whether one has presses the ENTER or RETURN key is neither here nor there.

The problem lies in, for the sake of argument, when one presses the 'Q' key how one detects whether at that moment the ENTER or RETURN key is being pressed.

[tperry2x]

Here's one possible way you could do it, but I now see what you meant.
It's not as easy as it first appears.
You can get the event with them down to fire, but you only see it briefly before it resets. This is sufficient to trigger another function of your choice though.

[OpenXTalkPaul]

One cannot poll the rawKeysDown, only keysDown, and as the ENTER and the RETURN key ONLY return a rawKey signal . . .

My main 'beef' is that xTalk is inconsistent here (and with arrowKey).

YES, you can, sort-of, just have to check if either number is 'among the items of the keySDown' -- Note the 'S' in the middle!

I posted two handlers previously in this thread that should work as stand-ins for lack of returnKeyDown() or enterKeyDown() on the engine level.

[richmond62]

either number is 'among the items of the keySDown

You cannot poll those numbers as they are rawKey numbers.