| Time |
Nick |
Message |
| 01:25 |
|
YuGiOhJCJ joined #luanti-dev |
| 02:05 |
|
Eragon joined #luanti-dev |
| 02:08 |
|
Confines joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:14 |
|
YuGiOhJCJ joined #luanti-dev |
| 04:25 |
|
Confines joined #luanti-dev |
| 06:20 |
|
SFENCE joined #luanti-dev |
| 06:39 |
|
SFENCE joined #luanti-dev |
| 08:45 |
sfan5 |
merging #16638 soon |
| 08:45 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16638 -- Fix missing airlike buffer info by cx384 |
| 09:22 |
|
Warr1024 joined #luanti-dev |
| 09:47 |
|
Warr1024 joined #luanti-dev |
| 10:19 |
|
YuGiOhJCJ joined #luanti-dev |
| 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 |
<wsor4035> 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. |
| 10:51 |
|
panwolfram joined #luanti-dev |
| 11:28 |
[MatrxMT] |
<Zughy> sfan5: translations should go through Weblate anyway, so it's a bit a non-problem |
| 11:30 |
[MatrxMT] |
<Zughy> *of a |
| 11:30 |
[MatrxMT] |
<Zughy> a bit off topic: we should set it up for builtin too, we can't expect translators to be professional git users |
| 11:46 |
|
turtleman joined #luanti-dev |
| 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] |
<y5nw> 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 |
| 13:24 |
|
SFENCE joined #luanti-dev |
| 13:27 |
|
SFENCE joined #luanti-dev |
| 13:48 |
|
SFENCE joined #luanti-dev |
| 14:10 |
|
pgimeno joined #luanti-dev |
| 14:38 |
Krock |
I'll make a follow-up PR. |
| 14:39 |
|
Confines joined #luanti-dev |
| 15:00 |
|
SFENCE joined #luanti-dev |
| 15:10 |
|
SFENCE joined #luanti-dev |
| 15:23 |
|
rubenwardy joined #luanti-dev |
| 15:23 |
|
rubenwardy joined #luanti-dev |
| 17:54 |
|
Desour joined #luanti-dev |
| 18:06 |
|
SFENCE joined #luanti-dev |
| 18:27 |
|
mrcheese joined #luanti-dev |
| 18:32 |
[MatrxMT] |
<Zughy> 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] |
<y5nw> 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] |
<y5nw> ... 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] |
<y5nw> 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] |
<y5nw> 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] |
<y5nw> 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] |
<y5nw> 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] |
<y5nw> Not to mention that such comparisons are likely to produce inconsistent results that are not suitable for e.g. hash tables |
| 19:06 |
[MatrxMT] |
<y5nw> 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] |
<y5nw> 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] |
<y5nw> (I mean translating keycodes to scancodes) |
| 19:12 |
[MatrxMT] |
<y5nw> 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] |
<y5nw> 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] |
<y5nw> 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] |
<y5nw> 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 |
|
MTDiscord1 joined #luanti-dev |
| 19:27 |
[MatrxMT] |
<y5nw> 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] |
<y5nw> "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:29 |
|
MTDiscord2 joined #luanti-dev |
| 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] |
<y5nw> 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] |
<y5nw> Krock: Didn't you suggest the option to assign keys by keycodes? I would except you to be able to answer that |
| 19:33 |
|
BuckarooBanzai joined #luanti-dev |
| 19:33 |
|
repetitivestrain joined #luanti-dev |
| 19:34 |
|
behalebabo joined #luanti-dev |
| 19:35 |
[MatrxMT] |
<y5nw> (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] |
<y5nw> My suggestion has been to use scancodes for keybindings |
| 19:38 |
|
user333_ joined #luanti-dev |
| 19:38 |
|
sugarbee1 joined #luanti-dev |
| 19:38 |
|
fluxionary joined #luanti-dev |
| 19:38 |
|
sofar joined #luanti-dev |
| 19:46 |
|
user333_ joined #luanti-dev |
| 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] |
<y5nw> 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] |
<y5nw> 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] |
<y5nw> 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 |
| 21:09 |
|
whosit joined #luanti-dev |
| 21:24 |
|
repetitivestrai- joined #luanti-dev |
| 21:24 |
|
BuckarooBanzai4 joined #luanti-dev |
| 21:59 |
|
SFENCE joined #luanti-dev |
| 22:00 |
|
YuGiOhJCJ joined #luanti-dev |
| 23:18 |
|
mrcheese joined #luanti-dev |
| 23:26 |
|
mrcheese joined #luanti-dev |
| 23:32 |
|
panwolfram joined #luanti-dev |
