Time Nick Message 08:45 sfan5 merging #16638 soon 08:45 ShadowBot https://github.com/luanti-org/luanti/issues/16638 -- Fix missing airlike buffer info by cx384 10:25 sfan5 web#369 why are we in a hurry to merge a translation without letting a native speaker read over it? 10:25 ShadowBot https://github.com/luanti-org/luanti-org.github.io/issues/369 -- Add german by helpme970 10:27 sfan5 to be clear there are only a few minor issues 10:27 sfan5 but still why??? 10:28 MTDiscord Could have waited 4 years to merge it if we follow the engines lead i suppose 10:37 Krock I would argue that leaving feature PRs open for review/inputs for a few days would be a good measure. 10:38 Krock But it depends on the quality you are striving for. 11:28 [MatrxMT] sfan5: translations should go through Weblate anyway, so it's a bit a non-problem 11:30 [MatrxMT] *of a 11:30 [MatrxMT] a bit off topic: we should set it up for builtin too, we can't expect translators to be professional git users 11:49 Krock Zughy: builtin is already contained in weblate 11:50 Krock wait. only the settingtypes file is. 11:50 Krock and any explicit gettext calls 11:51 Krock we'd first have to move to the client-side gettext format instead of using our homebrew format 11:52 Krock unless there is a page on weblate to directly edit the files...? At least it wouldn't be as convenient as it currently is with the gettext interface 12:50 [MatrxMT] The thing with translating builtin is that there are two parts: one that specifically focuses on the client side (e.g. setting menu) and uses gettext() directly, and one that is run on the server and then uses client-side translations 13:19 Krock Q: Shall I extend #16640 or create a new PR after that one's merged? I found some more headers to debloat. 13:19 ShadowBot https://github.com/luanti-org/luanti/issues/16640 -- Break include chains and tidy by SmallJoker 14:38 Krock I'll make a follow-up PR. 18:32 [MatrxMT] No meeting points so I suppose no meeting 18:45 Krock goshdarn it. SDL3 SDL_GetKeymapKeycode(SDL_GetCurrentKeymap(), scancode, keymod) returns exactly what I'd like to have... only problem being that it's not exposed. 18:48 [MatrxMT] Krock: SDL_GetKeyFromScancode ? 18:50 Krock y5nw: no, that's not the same. my snippet returns the letters as if they were typed into an input box 18:50 Krock SDL_GetKeyFromScancode converts the thing to lowercase 18:51 [MatrxMT] ... what are you trying to do? 18:52 Krock oh! The key_event parameter must be false! 18:53 Krock I want my "/" hotkey back (in the long run) and as a first step, I am trying to reimplement KeyInput.Char field like it used to work before 18:53 [MatrxMT] I would suggest dropping KeyInput.Char entirely and instead rely on keycodes 18:54 Krock yes, that too. 18:54 Krock (agreeing to the latter. KeyInput.Char needs fixing regardless) 18:56 [MatrxMT] If you want to unambiguously identify a key (with modifiers) then the most reasonable way is IMO still keymod+scancode. For keycode-based settings I would suggest (temporarily) introducing a resolution algorithm that uses the keycode-based setting (translated to scancodes) if it does not conflict with other defaults 18:59 Krock actually I don't want an unambiguous way in this case. First, 'Char'-bound key bindings should be triggered, and then either scancode or keycode ones. 19:00 [MatrxMT] With said resolution you can still have keybindings that _appear_ (in a limited extent) to be based on keycodes while avoiding various issues that come with mixing scancodes and keycodes for keybindings 19:00 Krock (.. priority-wise). The defaults would be chosen such that collisions should not happen - e.g. by using scancodes for the usual WASD 19:02 [MatrxMT] That is my suggestion as well. Except resolving conflicts in the default setting (e.g. zooming in AZERTY) can already be done by using (keymod, scancode) pairs (as the resolution code can be placed on top of that); do I'm not sure why there should be a Char -> scancode -> keycode fallback (for comparisons I suppose?) 19:03 [MatrxMT] Not to mention that such comparisons are likely to produce inconsistent results that are not suitable for e.g. hash tables 19:06 [MatrxMT] IMO the resolution code only needs to run on startup to check whether certain defaults can conflict each other; this can be done with a less (temporally) deterministic comparison, e.g. comparing keycodes with scancodes (which can be done by converting said keycodes to scancodes). Then the keybinding system can continue working with scancodes (by reading keycode-based settings) 19:10 Krock It all comes down to whether you want to bind a key based on its physical location or what is written on it. I think we should allow both. 19:10 [MatrxMT] That would not 100% work like keycodes as the keybindings are still bound to physical keys. This would not work well when someone changes keyboard layouts, but basing keybindings on top of keycodes has its share of issues. 19:11 [MatrxMT] (I mean translating keycodes to scancodes) 19:12 [MatrxMT] For the moment I would prefer to not allow both beyond default settings. Otherwise you end up with a lot of issues 19:13 [MatrxMT] E.g. If I start Luanti with a QWERTY/QWERTZ layout and then switch to AZERTY, should the zoom key then be unbound? (Does SDL report keyboard layouts being changed?) 19:14 celeron55 i agree keycode bindings are a good example of a footgun. we were stuck with those for a long time of course and they got incorporated into some people's usage patterns, but they're still a footgun 19:15 [MatrxMT] I mean, keycodes are sensible for default settings; but then the scope of things going wrong can be much more limited (as I described with the keycode -> scancode resolution; I wrote it before but lost it to a force-push) than having players flexibly bind to both keycodes and scancodes 19:15 celeron55 you only have to go as far as pressing shift in order to type "/" in order to notice the first bullet coming at you. that is, shift is already bound to something else... 19:17 celeron55 and then of course the next thing you do is change your keyboard layout and then it's like you ran into a minefield 19:23 Krock celeron55: that's where key press priorities come in. If the assignment does not work for you, then it's probably not a good assignment. 19:24 Krock y5nw: "If I start Luanti with a QWERTY/QWERTZ layout [...]". Unfortunately I do not switch keyboard layouts, thus cannot tell whether that would be a problem. I'd however not clear the assignment. 19:25 [MatrxMT] Krock: ... except this is a behavior to define if we support both binding to keycodes and binding to scancodes 19:26 Krock of course. Defining is not the issue there IMO, unless I am missing something. Assigning to keycodes should be an optional feature for those who want it. 19:27 [MatrxMT] I.e. what if two keybindings conflict when _after_ switching keyboard layouts. Which is why I suggested limiting this to startup and using scancodes - then the answer is "no, these are based on keycodes only (1) for the layout that is used on startup and (2) if the default does not conflict with another (scancode-based) default; otherwise a fallback is used" 19:29 [MatrxMT] "using scancodes" as in translating keycode-based settings to scancodes as soon as we can figure out default settings that do not conflict. Then the user can only assign scancode-based keybindings 19:29 celeron55 it doesn't need to be stated that adding options where 99% of users ask "why would anyone use this?" is going to be controversial 19:31 Krock y5nw: what if the user assigns a new binding with a keyboard layout that is unlike the one upon startup? Which scancode would it resolve to? 19:31 [MatrxMT] The other issue is how you convey the concept of keycodes and scancodes to the user (most of which - realistically - only use one layout, in which case the difference is largely negligible) 19:32 Krock ("resolve to": if assignment by keycode were an option) 19:32 [MatrxMT] Krock: Didn't you suggest the option to assign keys by keycodes? I would except you to be able to answer that 19:35 [MatrxMT] (My proposal for resolving keycode-based defaults at startup is to limit this to the default keybinding - which the user can't change - and with the keyboard layout that is used when Luanti is started - then these are translated to scancodes and handled as such, and users can only assign to scancodes.) 19:36 Krock I am kind of confused by your statement "Which is why I suggested limiting this to startup and using scancodes - then the answer is [...]". I would resolve them at all to scancodes. The keys would be input like what the user is using. If they decide to switch, and that happens to cause a collision, then I'd suggest them to use scancodes instead of keycodes. 19:37 Krock s/would resolve them/wouldn't resolve the keycodes/ 19:37 Krock either way, using scancodes for everything, with alternatives, can lead also provide a solution 19:38 [MatrxMT] My suggestion has been to use scancodes for keybindings 20:00 Krock y5nw: Do you happen to know what wchar_t in Keycode is supposed to hold? According to getKeyFromScancode it's a keycode, and according to getKeyFromScancode it's a scancode. So... it's variable depending on the context? 20:04 Krock to be clear: by 'it's a keycode' I meant an SDL keycode, as passed and returned to and from findCharToPassToIrrlicht 20:06 [MatrxMT] The getKeyFromScancode in Irrlicht? The wchar_t component in the return value should be a character 20:09 Krock Yes, that one. I would assume that too, and yet the same `Keycode` struct also holds a scancode, if getKeyFromScancode is to believe. This is kind of puzzling. 20:10 [MatrxMT] The Keycode struct holds a EKEY_CODE which is actually a keycode (not a scancode) 20:10 Krock oh it's just IrrlichtDevice::getKeyFromScancode that has a very strange stub implementation 20:11 [MatrxMT] That one is a stub for non-SDL devices where I did not implement scancode handling 20:18 sfan5 merging #16640, #16642 in 10m 20:18 ShadowBot https://github.com/luanti-org/luanti/issues/16640 -- Break include chains and tidy by SmallJoker 20:18 ShadowBot https://github.com/luanti-org/luanti/issues/16642 -- Default-initialize SColor by sfan5