Add Hungarian keyboard layout.

[L3-NR]

Modified from the already existing german layout. Based the layout mostly on my IRL keyboard, with some extra functionality present on hungarian layouts i've seen online.

[elvissteinjr]

Looks good to me. Thank you for your efforts.

Before I just merge though, the shift sub-layout numpad is an interesting approach. But isn't Insert missing on the numpad 0 key then?
I can't comment on typical labels for Hungarian keyboards, but "NumL" looks a bit like the unfortunate consequence of "NumLK" not fitting there. Would using a two-line label make more sense perhaps?

[L3-NR]

The shift sub-layout on the numpad is just how it behaves under windows, yes including shift+numpad 0 acting as shift+insert.
Fair point with the Insert, I failed to notice that due to missing labeling on the numpad 0 key on my IRL keyboard.
Also going to change the num lock key to be two-line.

[elvissteinjr]

I vaguely remembered having a reason not to have different sub-layouts for the numpad in the official keyboard layouts, so I checked out how the numpad input simulation actually behaved (something I have to admit to never really have done beyond the simple key presses).

Desktop+'s numpad input simulation is inadequate to say the least. Major issue is that the shift state gets stuck for some reason when used with numpad keys (seemingly only those). Whether Shift+numpad key actually holds shift on a real keyboard also depends on the numlock state it seems.
Numpad versions of the keys also have different scancodes (extended flag missing), so just using the regular ones isn't technically correct (likely not going to make a difference in practice though). Desktop+ doesn't allow specifying this, however.

None of this has your keyboard layout at fault. You basically made me check properly for once and now I want to fix this for all layouts.
Anyways, my point is that I'd like to actually wait a bit before merging this to see if all or at least some of this can't be resolved with a bit of special casing for numpad keys. In theory you'd want to set the shift sub-layout to use the same numpad keycodes then and get correct behavior automatically, but we'll see.

I'll report back after I had time sorting that little mess out. Thanks again.

[L3-NR]

For reference on windows with an IRL keyboard (at least on hungarian keyboards):
Shift + Num4:
Behaves like LeftArrow when num lock is on
Behaves like Shift+LeftArrow when num lock is off
Shift + Num0:
Behaves like Insert when num lock is on
Behaves like Shift+Insert when num lock is off

So it seems that when num lock is off, the key simply behaves like it would when pressed together with shift.
And when num lock is on, and you press it with shift, it behaves like it would with num lock off (and doesn't register the shift).
(This is something that I only learned today too, doesn't seem to be a thing that most people actively use lol.)

A possible, but still not perfect solution (if all else fails) would be to make it so that the numpad keys switch to the numpad layer keys (like in this layout) only when num lock is off.

I indeed tried to accomodate for this by approximating the shift+numkey behavior by modifying the layout, but indeed this can come off as kinda janky and is probably only optimal for pure text input, and likely not other use cases. Also it doesn't accomodate for users who are used to having num lock off and shift+numkey just toggling the num lock layered keys.
In day by day usage i saw no difference between this and using my IRL keyboard, but I can imagine how this can introduce issues in niche use cases or with (custom) keyboard bindings in other applications. (Ie. something requiring shift to be held down and then you can't access functions bound to a numpad key.)

Thanks for being thorough with this and looking into it, this is the sort of issue that usually doesn't even get noticed (at least until one user tries doing something specific and gets confused and frustrated).

[elvissteinjr]

Sorry for the delay. I've pushed something that I believe results in correct numpad behavior when using the normal numpad keycodes now.
Numpad off, numpad off + shift, numpad on, numpad on + shift & numpad on + both shifts... should all behave the same as a real keyboard input now. Unless I missed something.

I'm not too sure what to do about the labeling, however. I am toying with the idea of optional indicators on the various toggle keys (would be a global setting, nothing layout specific), but accurate reactive numpad labels might be more trouble than worth.

All of this aside, while I'd lean towards using the same keycodes and maybe also labels on the shift sub-layout now, I'm not really looking to judge community keyboard layouts harshly. So just go with what you feel like.
If you think it is fine as it is right now, I'll merge it as that. No problem.

[L3-NR]

Alright, i'll go ahead and change the numpad keys back to being numpad keys always.
Also, quick question before I make a commit, would something this for the labeling be better?:

(adding the NumLK off keys as extra sub-labels in the layout itself)
(and then the shift layer having just the NumLK off keys as labels (but still the numpad keycodes), since they always acts as a NumLK off input with shift held down)
Or would this just come off as a janky way to get around not having reactive labels?
(I do agree that reactive labeling would be a bit overkill tho)
Just trying to work with what we have, even tho this makes the labeling look a bit inconsistent, most IRL keyboards have this labeling because half the functionality of the numpad is the NumLK off keys.

[elvissteinjr]

That labeling would also work, sure. Only thing that bothers me there is the 5. An empty second line should align it fine with the others (as long as the line isn't empty, so add a space character).

The recently added Korean layout actually does this as well. Though it's also full of additional labels on most keys for IME input so it didn't actually stand out much to me.
But even without that, while it may be considered a bit busy looking, it's off in its own block to the side so I personally don't mind it and might update other layers to this as well.

[L3-NR]

Ok, I changed it but there seem to be some issues regarding labels that prevent me from doing that.

-The text itsn't actually aligned to the center, it's just positioned to the center, meaning that if you have multiple lines on a label, and one line is longer than the other, then the longer line will be center, but the shorter line will be aligned to the left, to the edge of the longer line
-The keyboard editor and the actual VR overlay ignores extra spaces when loading up a saved keyboard.

So you can try to align the shorter lines (like the numbers) to the center by spamming spaces (janky, but ehh), and it will appear correctly in the editor and also save correctly (the layout file will have the spaces in it), but when loading it back up in either the editor or vr overlay, the extra spaces get ignored.
It also ignores lines that are just a \n and a space, so num5 jumps back to the center vertically.

Before saving:

After saving and loading:

The actual file: (correctly saves the spaces)

So, should I make a commit with the extra sub-labels removed (since it's just a fancy extra), or is this something that's going to be fixed in a later version?
If it is going to get fixed, should I keep the janky extra spaces on the shorter lines that keep them centered, or only the extra line and space on num5?

[elvissteinjr]

The ini reading functions helpfully removed trailing spaces in property values. Technically can be worked around by using one of the many other whitespace characters that exists but that behavior isn't actually what I wanted in the first place (not my code) so I just got rid of it. Thanks for noticing.

As for general text alignment, I was somewhat hesitant to allow introducing too much processing per button label since this stuff was rendering all time as long the keyboard window was visible even if inactive and there's naturally going to be many buttons on a keyboard. But with the idle improvements from a while ago I don't see a reason not to do it properly.
Dear ImGui doesn't do the centered button labels per line so I'll have to jump in and draw each line separately. Not a huge deal but I'll need to get to it first.

As for whether you want to wait for that or not is up to you. I have no issue fixing the layouts up later to take advantage of proper centering. Probably will have to do on some layouts anyways.

[L3-NR]

OK, sorry for the late response.
Updated the layout accordingly, and without the extra spaces to center the text.
Will look off until individual line centering gets introduced, but at least it won't be janky after that.
Kept the extra line to align num5, hopefully it won't get cut off.

[elvissteinjr]

I thought I might be able to quickly sort the alignment out but didn't have time to do it yet. No reason to leave this hanging though, so I went ahead and merged it. Thanks again.

This will be sorted out before this makes it into a release, no worries.