formspec key, mouse and touch events

For people working on the C++ code.
Post Reply
loosewheel
Member
Posts: 155
Joined: Mon Dec 28, 2020 01:19
GitHub: loosewheel
In-game: loosewheel

formspec key, mouse and touch events

by loosewheel » Post

Just a question about formspecs code. In the GUIFormSpecMenu::OnEvent function the form is dismissed if the inventory key is pressed, or the enter key is pressed and m_allowclose is true. Can this behaviour be suppressed by formspec properties (I couldn't see anything in the docs). I'm experimenting with sending key, mouse and touch events to the on_receive_fields callback. Usually you would lose the escape and some F* keys, but losing i and enter leaves a bit of a hole in a key event feature.

wsor4035
Member
Posts: 182
Joined: Sun Aug 11, 2019 21:23
GitHub: wsor4035
IRC: wsor
In-game: wsor

Re: formspec key, mouse and touch events

by wsor4035 » Post

j5uBLfc6NxgersvVj5D5dIsiKDkoQb0o

User avatar
rubenwardy
Moderator
Posts: 6969
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: Bristol, United Kingdom
Contact:

Re: formspec key, mouse and touch events

by rubenwardy » Post

loosewheel wrote:
Sat Jul 02, 2022 13:41
Just a question about formspecs code. In the GUIFormSpecMenu::OnEvent function the form is dismissed if the inventory key is pressed, or the enter key is pressed and m_allowclose is true. Can this behaviour be suppressed by formspec properties (I couldn't see anything in the docs). I'm experimenting with sending key, mouse and touch events to the on_receive_fields callback. Usually you would lose the escape and some F* keys, but losing i and enter leaves a bit of a hole in a key event feature.
Use field_close_on_enter[<name>;<close_on_enter>] to stop enter closing the formspec

https://github.com/minetest/minetest/bl ... .txt#L2588
Renewed Tab (my browser add-on) | Donate | Mods | Minetest Modding Book

Hello profile reader

loosewheel
Member
Posts: 155
Joined: Mon Dec 28, 2020 01:19
GitHub: loosewheel
In-game: loosewheel

Re: formspec key, mouse and touch events

by loosewheel » Post

rubenwardy wrote:
Sat Jul 02, 2022 17:32
...

Use field_close_on_enter[<name>;<close_on_enter>] to stop enter closing the formspec

https://github.com/minetest/minetest/bl ... .txt#L2588
This only suppresses the behaviour for a particular field. It would be needed to be suppressed for the whole form.
Thanks for the link, I wasn't aware of that. Its probably pointless to continue, because I've probably done something similar and will fail for the same reason.

loosewheel
Member
Posts: 155
Joined: Mon Dec 28, 2020 01:19
GitHub: loosewheel
In-game: loosewheel

Re: formspec key, mouse and touch events

by loosewheel » Post

Sorry, back again. I got bored so I continued anyway.

The issue with the PR seemed to be that the key codes were not consistent across platforms, or similar. I wasn’t really concerned with this while experimenting, because the events are generated by irrlicht and irrlicht defines it’s key codes in Keycodes.h. I assumed they would be consistent.

Its probably better to use virtual codes rather than trying to represent the physical keys. If you implemented the number pad zero for a purpose then half the people using Minetest can’t use it because they don’t have that key. Porting symbolically similar keys to a single key code is simpler to implement. C++ is more efficient than lua. Delivering brief, readily consumable data to the lua code keeps the less efficient code to a minimum.

The place I found had some ambiguity was the character field and the context of the key event. The event details whether the Shift and Control keys are depressed, but not the Alt key. In the implementation the character field, which is a wide character, was translated into a single utf-8 character string for the event. During testing pressing C emitted ‘c’, Shift+C emitted ‘C’, and Ctrl+C, …, I don’t know because I was dumping it to chat, but it printed out as at least 2 blank characters. Ctrl+C is usually trapped to perform an action, not as valid input. It would be better to omit the character field unless it is valid input, but without knowing the state of the Alt key this isn’t really possible. It can be done in lua, as the Alt key emits press and release events. The state of the key can be tracked and the character ignored as appropriate. This is cumbersome and not fully reliable, as the whole press and release process may not take place while the form is open.

Looking at the irrlicht code the individual platform implementations are in the various CIrrDevice* files. The docs for the various platforms specify masks for the Alt key, except for the following:

Linux X. ShiftMask and ControlMask are specified and used. The remaining masks are LockMask, Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, and Mod5Mask. I’m assuming Mod1Mask could be it, but without documentation experimentation is required to determine that. The Alt key would be on nearly every keyboard running this system. The state of the Alt key should be get-able.
Mod1Mask appears to be it.

ios code has no mention of key events, only touch events. I assume key events are not relevant on this platform.

Android always sets the Control key state to false, assuming this platform doesn’t have one. I’m not that familiar with this platform, but think it likely the same for the Alt key (the Shift key is set).
Android does have masks for an Alt key, as well as Control key. I think this could be implemented and the Control key could be set.

I think this is do-able without too much fuss. The PR was closed without implementation. Is this a dead issue or is there still an ambition to implement this in the engine?

User avatar
Hugues Ross
Developer
Posts: 72
Joined: Mon May 06, 2019 22:52
GitHub: Df458
Location: Kitchens, Pantries, etc.
Contact:

Re: formspec key, mouse and touch events

by Hugues Ross » Post

Is this a dead issue or is there still an ambition to implement this in the engine?
It was just a policy-based closure because the developer left feedback unaddressed for over a month. I don't think anyone would mind seeing someone take another crack at it.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest