TI-nspire CX CAS: Keypad Input/Mapping Enhancements

[cgloeckner]

Hi,

there are multiple keypad input enhancements, some important, others optional. Sorted from by importance (most important at the top, imho):

Division Operator
Typing / (using number keys) places \. So no division can be entered using the / on the numbers above the keyboard's letters; using the numpad equivalent works fine.

Del Key
The del key behaves just like backspace: it deletes the character to the left (but is assumed to delete the character to the right of the cursor).

Caps Lock
In CX CAS pressing ctrl followed by shift enteres the CAPS mode. Is there a way to use the native keyboard's caps lock key to control this behavior?

Home/End Mapping
Home maps to the on-Key and End to the Scratchpad, which is tricky: When selecting a part of a calculator line, the user may use Home and End to navigate the current line. Maybe the context menu key could be used here, but it'd make things even less intuitive... Maybe the Pause key could be used for on?... I don't have a good suggestion here, yet.
Btw I like the binding of PageUp/PageDown for doc and menu ❤️

Assignment Operator
I'm used to type function declarations using := by entering : followed by = (instead of using the TI's definition feature via ctrl), since the TI Teachers Software for the CX CAS supported this. The Firebird Emulator ignores the : altogether.

Factorial and Percentage Operator
I'm used to type in ! and % directly, based on my experience with the TI Teacher Software for CX CAS.
Entering ! using my computer keyboard does not lead to factorial, neither leads % to automatic percentage conversion.

Lesser/Greater Operator
Typing < or > does not work as expected. According to the keybinding, < creates E and > does not work (the flag symbol does nothing).

Tested with:

• firebird-emu v1.6
• using TI-Nspire CX CAS v4.5.5.79
• Linux Ubuntu with qwertz Keyboard Layout

glocke

[Vogtinator]

I think it would be better to have a single issue for keypad input enhancements.

[cgloeckner]

Sure. I'll point the others to this issue and I'll change the opening post accordingly.

[complanar]

Just realized that the ^-keyb on a physical computer keyboard does not map to ^ at the virtual handheld keyboard. Maybe this could be enhanced together with the above.

[complanar]

After reading the source in qtkeypadbridge.cpp I found out that many keymappings are not accessible for me, at least not with german keyboard layout on linux (other systems not tested). Additionally the window manager seems to grab the [ALT]-Key so that some of these key combinations trigger different actions related to the window manager instead of doing what qtkeypadbridge.cpp suggests.

[cgloeckner]

I cannot confirm the [ALT]-Key problem, because I configured my window manager to use the "Windows-Key" instead.

But fun fact on the / vs \: If I press [Shift] + [7] (in German Keyboard Layout this would produce /) I get \ inside the Emulator. Using [Shift] + [Alt] + [7] I get the correct /.

[Vogtinator]

But fun fact on the / vs : If I press [Shift] + [7] (in German Keyboard Layout this would produce /) I get \ inside the Emulator. Using [Shift] + [Alt] + [7] I get the correct /.

This happens because the calculator sees Shift + /, which produces \.

Maybe for non-alpha keys the modifiers should be ignored.

[cgloeckner]

This happens because the calculator sees Shift + /, which produces \.

How does the calculator gets notified about the modifier? As far as I understand the keybinding, Qt-Keys are mapped to Keypad-"Actions". Are Qt-Modifiers queried somewhere else, too?

[Vogtinator]

This happens because the calculator sees Shift + /, which produces .

How does the calculator gets notified about the modifier? As far as I understand the keybinding, Qt-Keys are mapped to Keypad-"Actions". Are Qt-Modifiers queried somewhere else, too?

It's just normal keys, pressing and releasing the shift key on the keyboard presses and releases the shift key on the calculator.

[cgloeckner]

Makes sense. I'm currently experimenting with the code: sending a release of the shift key before any div operation does not work - or at least my approach isn't suitable

if (translated != QtKeyMap.end())
{
    // here <----
    if (*translated == keymap::div)
    {
        // force release of shift key on any division
        setKeypad(keymap::shift, false);
    }
    // to here <---
            
    pressed_keys.insert(vkey, *translated);
    setKeypad(*translated, true);
}

I also tried

auto mkey = event->key();

// here <----
if (event->modifiers() & Qt::ShiftModifier && mkey == Qt::Key_Slash) {
    setKeypad(keymap::shift, false);
}
// to here <---

if (event->modifiers() & Qt::ShiftModifier && mkey == Qt::Key_Alt)
{
    setKeypad(keymap::shift, false);
    return;
}

Only workaround that helps me: Disabling the keybinding for shift altogether.

[Vogtinator]

I guess that happens for two reasons:

1. Shift is sticky by the OS. If there is no key press between pressing and releasing shift, the shift state remains until the next shift press (visible as the up arrow in the status bar).
2. The keypad isn't a queue, it's just an asynchronous bitfield. To generate events, some time has to pass between changing the state of keys.