Minetest logo

IRC log for #minetest-dev, 2024-08-05

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
04:00 MTDiscord joined #minetest-dev
04:13 fluxionary joined #minetest-dev
09:34 pmp-p joined #minetest-dev
12:44 fgaz_ joined #minetest-dev
13:15 [MTMatrix] <Zughy> So what are we going to do? Drop SDL2, ignore the `/` regression, fix it in a hacky way? And how about the mouse regression?
13:28 sfan5 I'm still in the ignore the / regression camp
13:30 [MTMatrix] <grorp> ignore or hacky fix are both fine by me
13:32 sfan5 the mouse thing seems to be a case of 🤷
13:33 sfan5 rubenwardy: in the interest of a quick 5.9 release I'd be fine with moving it to 5.10
13:33 sfan5 we should go and speed up our release game after this
13:33 sfan5 (replying to the message about 13987)
13:38 [MTMatrix] <Zughy> https://matrix.org/_matrix/media/v1/download/matrix.org/lTNdYnmOezfUTziRfBIrHIrZ
13:38 [MTMatrix] <Zughy> what's the correct character?
13:39 MTDiscord <rollerozxa> shrug emoji
13:39 [MTMatrix] <Zughy> thank you. So should I move to 5.10 or put a "won't fix"?
13:40 [MTMatrix] <Zughy> well, put it into 5.10 for now
13:42 [MTMatrix] <Zughy> Last question: after how much time we expect to release 5.10? Two months? Because if the release is short enough, I'm fine moving #13987 in there
13:42 ShadowBot https://github.com/minetest/minetest/issues/13987 -- [pls do not squash :3] Allow limiting object observers by appgurueu
13:43 [MTMatrix] <Zughy> I fear that, if release times are too short, it'll just stress you
13:54 basxto joined #minetest-dev
14:07 lhofhansl joined #minetest-dev
14:13 lhofhansl I feel it's more stress if releases are too far apart. In fact I have been managing large projects (as an architect), open source and proprietary for a while and found that some kind of train model is best.
14:13 lhofhansl I.e. the train comes by every n weeks and what's ready gets on the train, and what is not simply gets on the next train.
14:13 lhofhansl That way we (a) do not accumulate lots of changes with lots of potential bugs into a release, (b) no need to cram last minute changes into a release since the next release is soon, and (c) no flurry of merges towards the end of a release (with all the work to stabilize).
14:13 lhofhansl 2 to 6 weeks seemed ideal. Requirements are that you can skip releases when upgrading, and good testing.
14:13 lhofhansl Just $0.02.
14:13 lhofhansl And we'd need release branches.
14:40 MTDiscord <herowl> 2 weeks looks too short to me tbh.
14:40 MTDiscord <herowl> Most releases would have nothing worthwhile in that case.
14:41 MTDiscord <herowl> An interesting way would be in fact doing beta releases and making more use of point releases.
14:58 sfan5 a 5.8.2 was proposed but nobody wanted to put in the work to backport things
15:05 [MTMatrix] <Zughy> should we try two months then?
15:07 sfan5 even 3 - if we keep to it - would be better than the current 6 months + 1-3 months of delay
15:07 rubenwardy I'm up for trialling 2-3 months
15:08 rubenwardy yeah
15:10 [MTMatrix] <Zughy> Perfect then. I guess pgimeno/Krock suggestion can be discussed along the way, but in the meantime let's try with a shorter span of time
15:11 [MTMatrix] <Zughy> So basically there are only two things in the current milestone left: Brasilian and French builtin translation. Something we can't really review, so.. Easy peasy?
15:12 sfan5 someone could double check using google translate
15:12 sfan5 and for logical errors (e.g. @1 replacements)
15:12 sfan5 other than that we don't really review weblate translations either
15:14 [MTMatrix] <Zughy> Srifqi did, one has been fixed already. The other is basically just a couple of empty strings, nothing big
15:23 sfan5 I suppose we could do an rc build today then and unless someone finds a big problem release on the weekend?
15:51 SFENCE joined #minetest-dev
16:00 SFENCE joined #minetest-dev
16:14 rubenwardy Sounds good to me sfan5
16:26 SFENCE joined #minetest-dev
16:29 [MTMatrix] <Zughy> that'd be great
16:34 SFENCE joined #minetest-dev
16:40 SFENCE joined #minetest-dev
16:49 sfan5 fyi you don't need me for win32 builds anymore
16:52 SFENCE joined #minetest-dev
16:54 sfan5 https://github.com/minetest/minetest/commits/ci/ there we go
16:56 fluxionary joined #minetest-dev
17:05 lhofhansl joined #minetest-dev
17:06 YuGiOhJCJ joined #minetest-dev
17:07 lhofhansl +1 for 2-3 months. Maybe pick one and try to stick with it.
17:10 MTDiscord joined #minetest-dev
17:10 SFENCE joined #minetest-dev
17:11 lhofhansl With a preference for 2 months
17:13 SFENCE joined #minetest-dev
17:16 MTDiscord <athozus> I see that discussion now about 5.9 release
17:16 MTDiscord <athozus> First I agree with the proposal of closer releases (but not too close)
17:19 sfan5 hmm I just remembered we still need to update the credits before release
17:19 rubenwardy really need to move to a json format at some point, to share with the website
17:20 SFENCE joined #minetest-dev
17:21 sfan5 will post the 5.9.0-rc1 to the forums soon unless there are complaints
17:21 MTDiscord <athozus> iirw the main menu is in lua
17:21 MTDiscord <athozus> here's what we done for mail mod : https://github.com/mt-mods/mail/blob/master/ui/about.lua
17:22 MTDiscord <athozus> ah i thought the rc were for feature freeze
17:25 MTDiscord <nrz0> 3 month release ? less things integrated but shorten feature freeze due to less things to review ?
17:37 sfan5 https://forum.minetest.net/viewtopic.php?t=30853
17:57 Krock thank you very much, sfan5
18:00 sfan5 rubenwardy: do modpacks not have a "min_minetest_version"?
18:00 rubenwardy It's supported by all content types
18:01 rubenwardy modpack.conf not .txt
18:01 sfan5 hmm I see
18:07 MTDiscord <athozus> wait
18:07 MTDiscord <athozus> that's a very bad issue
18:07 MTDiscord <athozus> about the keybinds
18:07 MTDiscord <athozus> i'm unable to add or reduce viewing range
18:08 MTDiscord <athozus> i mean, i can change controls
18:08 MTDiscord <athozus> but +/- are the default keys
18:08 MTDiscord <athozus> and at least on Azerty (the French keyboard), - and + are under the numbers, in the top bar
18:09 sfan5 what do you press on your keyboard to produce + or -?
18:11 MTDiscord <athozus> just the key itself : https://img.phonandroid.com/2019/04/azerty-clavier.jpg
18:12 Krock I don't see any + key on there
18:12 sfan5 wouldn't that mean shift+6 to produce -?
18:12 SFENCE joined #minetest-dev
18:15 MTDiscord <athozus> In no dead-cases which is quite unusual
18:15 MTDiscord <athozus> https://cdn.discordapp.com/attachments/747163566800633906/1270082800569286656/Screenshot_20240805_201511.png?ex=66b26848&amp;is=66b116c8&amp;hm=e0b830119fad860aad9cd98b37fca6e16f292e70dc219b21ede2488492d16896&amp;
18:15 MTDiscord <athozus> And a lot of keyboards don't have the numbers side panel
18:16 Krock most desktop keyboards do have it. for laptops it's a hit&miss
19:42 MTDiscord <josiah_wi> Indeed. My personal laptop has them, my work laptop doesn't.
19:42 MTDiscord <josiah_wi> I feel a little vindicated that somebody complained about it.
19:55 luatic joined #minetest-dev
20:54 pgimeno I couldn't be present on the meeting, but I'd like to say that a dev branch looks like introducing more problems than solving, at least if I'm understanding correctly
20:54 [MTMatrix] <Zughy> not a core dev but I agree
20:55 pgimeno yeah, usual disclaimer: IANACD
20:55 pgimeno also, I see no one suggested an alternative hack for the "/" issue: to use the SDL textinput event instead of the key event, just for that purpose, and hardcoded (until a better solution can be found)
20:56 pgimeno Desour's proposal also seems reasonable
20:57 pgimeno (going back to the release method)
20:58 pgimeno note also that in my proposal, merging all in one day is not the goal; just merging all in one go (it may take several days if there are conflicts)
21:01 pgimeno switching to the scheme I proposed is easy and can be done right away, by merging all features that are ready at the time of the 5.9 release, immediately after the 5.9 release; there might not be many but that's OK. More effort can be put into fixing bugs, like the "/" problem.
21:01 sfan5 this hack has been suggested and does not work
21:02 pgimeno oh? what was the problem?
21:02 sfan5 among other things text input enables IMEs which totally breaks normal key input
21:02 pgimeno uh... love2d does not have such problem
21:02 pgimeno there's probably something being misused
21:03 pgimeno IIRC love2d has a function to explicitly enable/disable IMEs
21:04 MTDiscord <y5nw> SDL's text input API only allows starting and stopping text input mode which automatically enables/disables the IME
21:04 pgimeno yeah it looks like you're right, sorry
21:04 pgimeno https://love2d.org/wiki/love.keyboard.setTextInput
21:05 sfan5 someone mentioned that some sdl1/sdl2 wrapper makes use of this method
21:05 MTDiscord <y5nw> Aside from that: with the text input event you break keys like Shift+6 since it gives a different character than the number 6
21:05 sfan5 but that just means it's either a documentation limitation or nobody is aware that it's totally broken for many asian users
21:06 sfan5 documented*
21:08 pgimeno @y5nw I think that's desirable, only the "/" character should trigger the chat, whatever key it is bound to
21:09 MTDiscord <y5nw> pgimeno: well if I have e.g. 6 bound to select the sixth item in the slot without specifying the behavior for Shift+6 then I would expect Shift+6 to result in selecting the sixth item alot and sneaking
21:10 pgimeno that's the problem most people with European keyboards already have anyway
21:11 pgimeno shift+7 opens chat even if shift is bound to sneak and 7 is bound to select the 7th slot
21:11 MTDiscord <y5nw> (Ok, let's use shift+7. If I have a keyboard layout where Shift+7 is not  / then I would expect it to select the seventh slot while sneaking. That should not break for e.g. the US layout)
21:12 pgimeno it wouldn't if it uses textinput
21:12 pgimeno grorp's hack does cause this IIRC
21:13 MTDiscord <y5nw> It would since the textinput would only give you a string with whatever Shift+7 is bound to without telling you that the 7 or the shift key is held down
21:13 pgimeno but since it doesn't produce the "/" character, the textinput event would be ignored, and the keypressed event would work
21:14 pgimeno that's the theory, but apparently it doesn't work... I've just tried, the textinput event works all the time in love2d, even without using love.keyboard.setTextInput()
21:14 MTDiscord <y5nw> Then you have a problem: how do you tell whether to use the keypress or textinput event? And how do you make sure they are from the same key?
21:15 pgimeno @y5nw: you only use the textinput event if the character is "/"; you always use the keypress event no matter what
21:15 MTDiscord <y5nw> Remember that IMEs can produce textinput events without a keypress event even if the text input only involves a single keypress, e.g. when inputting fullwidth punctuation
21:15 pgimeno not a problem, every textinput event that does not result in "/" would be ignored
21:16 pgimeno oh I think I know where you're coming from... with scancodes that doesn't happen
21:16 pgimeno with scancodes you also receive events for dead keys
21:17 sfan5 according to SDL docs you only get text input events with SDL_StartTextInput. and calling SDL_StartTextInput enables IME which breaks normal key input
21:17 sfan5 there's no way this can work
21:17 pgimeno sfan5: I don't understand myself but love does this
21:18 MTDiscord <y5nw> pgimeno: the problem is that this can not be generalized to other keybonds that are affected, such as + (shift+= on the US layout)
21:19 pgimeno ofc
21:19 pgimeno my proposal was to treat "/" and only "/" specially
21:19 MTDiscord <y5nw> ... which does not fix any other related issue unfortunately
21:20 pgimeno everything else can be deal with using scancodes afaik
21:20 pgimeno dealt*
21:21 pgimeno http://www.formauri.es/personal/pgimeno/pastes/love-scancodes-textinput-main.lua
21:21 MTDiscord <y5nw> The zoom key is bound to Z by default which may have the scancode Y
21:21 sfan5 what about + and - on azerty?
21:21 MTDiscord <y5nw> (Also: what happens if I rebind the key for entering chat commands?)
21:21 pgimeno yeah that was already discussed, users will have to remap their keyboards once we switch to scancodes
21:21 pgimeno sfan5: ^ too
21:22 pgimeno @y5nw nothing special
21:22 MTDiscord <y5nw> Heh, that would not be fixed by the workaround apparently. Nevermind
21:23 pgimeno in the above example, both scancodes and textinput events are generated
21:24 sfan5 maybe I misunderstand but I thought we were still talkingon how to work around this on short term
21:24 pgimeno yes
21:24 pgimeno mid term, I'd like to see joshia's solution, and long term, SDL3
21:25 pgimeno josiah's*
21:27 MTDiscord <y5nw> Isn't grorp's PR the short(est)-term solution though? I would much like to see IMEs working for more than three years
21:28 rubenwardy many production games have been made with sdl2,  sdl3 shouldn't be required for a proper fix
21:29 MTDiscord <josiah_wi> I have a draft PR up for what it's worth, but it's only the Windows part of the fix and the scancode conversions are still incomplete.
21:29 sfan5 rubenwardy: many production games also use scancodes ;)
21:30 MTDiscord <josiah_wi> If we had a list of which keys are possible to bind and handle with that part of the event processing, that'd be helpful. Some keys such as the arrow keys have special handling and don't need to be included in the conversion table.
21:35 pgimeno sfan5: "calling SDL_StartTextInput enables IME which breaks normal key input" - how does it break normal key input?
21:35 pgimeno (on non-Android)
21:36 MTDiscord <y5nw> pgimeno: some IMEs work by having a user enter a sequence of characters and then selecting the result from a list of candidates. There is bo guantee that this generates keypress events
21:37 pgimeno ah, asian ones I guess
21:37 MTDiscord <y5nw> Or if you have certain punctuation keys mapped to fullwidth variants. Then you press the "." key and get a "。" text input event without a keypress event.
21:39 pgimeno without even a scancode?
21:39 MTDiscord <y5nw> No
21:40 pgimeno and does Irrlicht handle that correctly?
21:41 MTDiscord <y5nw> Well ... by only using text inout events wgen text input is enabled
21:42 sfan5 pgimeno: here's an example https://0x0.st/XVbO.mp4
21:42 sfan5 I press a and random direction keys a bunch of times and the return key at the very end. until then MT sees nothing at all
21:43 MTDiscord <y5nw> Also for Chinese IMEs it is a common default that pressing the Shift key toggles between Chinese/English text input (this is an IM feature independent from IM switching), so for some IMs (esp. on Windows) you also have the side effect of randomly toggling that mode when sneaking.
21:43 pgimeno then I wonder how Irrlicht "sees" the character "/" in these keyboards
21:43 pgimeno it might even be mapped to something else... it's like magic
21:43 MTDiscord <y5nw> Pre-SDL devices pass the modified keycode to Irrlicht. SDL passes the unmodified keycode
21:45 pgimeno sfan5: yeah I see the point
21:50 MTDiscord <y5nw> Also (less related here but potentially worth noting) if you have a sufficiently "weird" setup the order of the text input events is only based on when the input is "committed" and not related to the order of keypresses
22:00 pgimeno yeah but I was convinced that the other keypresses would get through as scancodes, it's a shame that they aren't
22:00 pgimeno don't*
22:01 pgimeno anyway, ok, let's trash the idea, it's not worth discussing it further at this point
22:02 pgimeno I just wonder if love2d has IME active from the beginning, it's very weird to me if it does
22:03 pgimeno that would interfere with lots of love2d games that don't even think of using love.keyboard.setTextInput(false) at the beginning, yet I haven't seen any players complaining that their IME interferes with the game keys
22:33 panwolfram joined #minetest-dev
23:05 Eragon joined #minetest-dev
23:42 cranez joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext