Possibly not on the very short term.
If / Whenever one contributes to the CEmu FLOSS code base some portable code to read and write key mappings from a file (presumably in a user's home directory, or e.g. AppData on Windows), leverage e.g. QKeySequenceEdit (suggested by Vogtinator), probably refuse multi-key sequences, and signal conflicts between mappings, certainly

FWIW, to me, Shift and Tab look equally unusual for 2nd. TIEmu uses Alt for 2nd and Control for DIAMOND, both of which were inherited from VTI.
I can't check VTI's mapping for the TI-Z80 series, as I can't seem to find out how to add new ROM images (TI-68k or otherwise) on a copy of VTI (both the original version and JM's much improved version) in a new place, after the initial stage where I added one old 89 TIB file and started it. The ROM wizard is not really what I want (and it supports only severely obsolete cables anyway); F12 provides me no way to add images through left clicking, right clicking or drag&dropping.

Hello again all! If you would like to make to icon for this program, feel free! Open to all, but of course it will be narrowed down to one. Icons should be in svg format, or 512x512 minimum in size. Vector based is preferred, of course. Thanks!

This is all great work! It goes without saying how useful this will be for TI-84+CE development!

Just to add my 2 cents, I feel that configurable key bindings would be a big plus. I'm sure we all have our preferences for [2nd], [Alpha], etc. Personally I've become very accustomed to the WabbitEmu default bindings, which I preferred greatly over VTI.

I completely understand the key binding things. But it simply doesn't make sense to have 2nd and Clear tied to the Shift keys. You can actually use the shift key now to type things . That's all that is different, and Qt doesn't support a difference between shift keys even. Please, people. The key bindings are not what you should be worrying about. Maybe later there will be a way to load custom ones, but that is extremely low priority.

I'm probably just getting old and fussy heh Regardless, I'm super excited for this! And whatever the key bindings are, I'll get used to it

I've just pushed a commit which lays out some groundwork for supporting multiple predefined keyboard mappings - for a start, "cemu", "tilem" and "wabbitemu". We'd have needed a way to switch the keymap between 83PCE and 84PCE at some point anyway.
Of course, the keymap preference is saved to and restored from the settings.
EDIT: and Mateo built on that work.

I wrote "groundwork", because, for now:
* the six keymaps definitions are effectively the same, the contents of the existing "cemu" 84+CE was copied and pasted;
* whether the emulated calculator is 83PCE or 84+CE is not taken into account for selecting the keymap; Limitation lifted by Mateo
* the only way to change the keymap (which yields no visible effect yet, per the above) is to edit the settings locations manually: the $HOME/.config/cemu-dev/CEmu.conf file on Linux, the $HOME/Library/Preferences/com.cemu-dev.CEmu.plist file on MacOS X, the HKCU\Software\cemu-dev\CEmu registry keys on Windows. Limitation lifted by Mateo

I'm sure that people who are used to other keyboard mappings better (however perverted said keyboard mappings may be ) will now scramble to implement them , and even make a settings dialog with three or more radio buttons
If Qt provides no way to make a difference between left shift and right shift, then there's probably no portable / reliable (enough) way to do it.

I'd recommend adopting jsTIfied's scheme, then, which is PTI's with [/]=CLEAR rather than right shift. Mateo, I think people are focusing on the key bindings so much because unfamiliar key bindings really slow down one's use of an emulator, so it's very noticeable to us.

Slash should be division, because that is what it is: A division symbol. Making the familiarity argument doesn't make sense; if a user is really more concerned about getting used to the 2nd and clear keys moving to a more reasonable and sane location; then I feel they are focusing on all the wrong things. Just my 2 cents; we will still try to fix this and make it better somehow

BTW, 2nd is semicolon, alpha is also tied to ', and backspace is tied to clear. Nice easy cluster rather than reaching across the whole keyboard each time.

Also, here's a real-world example of tying the [/] key to clear:

User: Oh cool, I just typed this crazy equation in because I couldn't find my real calculator. Now I just have to divide by 2....
User: NOOOO!!!! Everything is gone!!!! What is the division key? What kind of monster would do such a thing??? Gah!

I would write a custom keybindings widget to the code if I could.

*mutters something about not having QT on this computer because of how big it is and it requiring admin rights*

I gather from Kerm's post that there's at least one difference between WabbitEmu and PindurTI; does that post also mean that jsTIfied reproduces the PindurTI layout faithfully ?

Does any of TilEm, PindurTI and WabbitEmu use the same mapping as VTI does ?

Host / is the only mapping that makes sense for emulated /, so if host / maps to emulated CLEAR in PindurTI... where is emulated / mapped, exactly ?

I added multiple preconfigured keypad layouts based on various emulators. Most of them were done hackily within the limits of Qt, so don't expect them to be 100% accurate. I doubt that the Wabbitemu layout's shift keys work on more than a couple oses. I also haven't implemented generating multiple keypresses, so the TilEm layout diverges quite a bit.

Thanks jacobly! That is very helpful. Anywho, for those that are interested, the currently implemented layouts are CEmu, TilEm, Wabbitemu, PindurTI, and SmartView.

Pretty helpful, indeed

Sorry to continue with this, but not all of us use the US English keyboard layout, though. For me (Spanish keyboard), a semi-colon requires a shift press (shift+comma) and the apostrophe ' is where the dash '-' is on the US layout.

I don't think anyone really uses the VTI layout anymore, since PindurTI came out in 2004/2005 i haven't even touched VTI. I've configured TilEm2 to use TAB for 2nd, i can't remember why now. I think it was because i had trouble getting the shift keys to work properly when i first set TilEm up.

I guess it's not a huge deal, but many of us have been using these mappings for over a decade now, that's where all the fuss comes from Anyway, thanks for the great work everyone, it's really great to see these projects come up and people working on them together as a community.

Notably, QT doesn't require admin rights if you install it to your own user profile.

Yep, there's support for a lot of different default mappings now. Probably will be configurable with a file at some point as well.

Thanks for listening to us about the key bindings. As Chickendude says, it's muscle memory at this point, and being familiar with the key bindings makes debugging a lot faster and more pleasant. Out of curiosity, what new features have you guys been working on lately?

Some neat features:

OP register table to easily veiw status of OPs]
VAT table veiw, with ability to jump directly to variable data
Load a symbol table file to view equates and labels directly in the disassembly
A battery slider/charging simulator
Ability to directly modify LCD registers
Search for hex strings in memory
Easily scalable screen with ability to turn skin on and off
Highlighting of any changed registers when entering the debugger
New Icon
Drag and drop with multiple file loading
Multiple keypad bindings available
And a whole lot more

Still a few more things to do, including speeding up block instructions and a fancy new keypad, but things are moving right along.

This project is coming along awesomely!

Dare I ask if the hex search was inspired by the jsTIfied feature request that I wrote myself a couple of days ago? This is really impressive work, especially considering how fast you guys have gotten all of these features completed. That all makes sense to me except the highlighting of changed registers part; not having tried the feature yet, can you please explain what that is? It sounds like pausing will highlight all of the registers that have changed since the last time you paused, but that doesn't sound as useful as I'd expect. Perhaps each time you step it highlights the register(s) that have changed?