Time Nick Message 02:23 MTDiscord Looks like I'll be able to get the Windows fix done tomorrow except for the scancodes I can't test. I'm planning to PR the Windows fix separately so at least that can get in even if I don't have time to fix it on Linux. 02:24 MTDiscord I have all the code done and I spent some time polishing it and doing the necessary ifdefs. 02:25 MTDiscord There are just a bunch of scancodes that don't work yet. I have all the letter and number keys (but not numpad) working on QWERTY keyboard in addition to a few symbols. 09:29 sfan5 so the fix is layout-specific? 10:00 celeron55 anyone have comments about adding cx384 to the core team also? 12:25 Krock celeron55: déjà vu. Might we already have brought that up a few months ago? Although I don't remember what the verdict/result was... 12:26 celeron55 my notes say i hadn't yet asked about it here 12:27 celeron55 in other places, sure, but that's not official 12:28 Krock okay. no objections from my side. 12:29 celeron55 i'll add sfence to the team on github now 12:30 [MTMatrix] +1 12:30 celeron55 (but that was already RFC'd earlier) 12:30 Krock (for context: asked on 2024-07-29, but I missed it) 12:31 [MTMatrix] I actually meant to +1 the message before that, but sure, that too 12:31 Krock perhaps adding a poll as a discussion on GitHub would be more helpful so that it's representative 12:32 Krock then again, that's probably not enough official..? 12:32 celeron55 well, i haven't yet done that, but there's also that i do like to also hear comments from outside the core team 12:33 celeron55 i might have to move these to there or onto the forum or something, if IRC continues to dry up 12:34 Krock or just me not paying attention :3 12:35 celeron55 i mainly don't like github discussions because 1) it's not public, not even readable, 2) vendor lock-in 12:36 Krock I totally agree 12:37 celeron55 IRC is publicly readable from three sources: 1) actually being on IRC, 2) on the discord bridge, 3) the public logs 12:37 celeron55 and there's no vendor lock-in, or more specifically libera is a non-profit organization and you can choose between multiple clients 12:38 celeron55 i can't rationally pick anything else, literally anything else is worse 12:40 Krock at the end it's a chat. It's not meant for persistent content. Logs are nice but important messages can be missed easily when there's no ping. Thus, your suggestion of using the forums seems acceptable. 12:41 Krock (no ping or no NOTICE, or TOPIC) 12:45 celeron55 probably need to do a poll about where people would want each kind of content to go 12:46 celeron55 my point obviously isn't to talk to myself so it doesn't really matter what i like 12:49 celeron55 on IRC, i haven't really seen anyone using NOTICE at all, and i don't think TOPIC acts as a notification on any client 12:50 celeron55 if this brought you to look at this channel, raise your hand (and note that this is the time to comment about cx384 being added to the core team soon) 12:51 celeron55 at least the discord bridge didn't make that anything noticeable at all. i guess for that i'd need to do this: @all 12:52 celeron55 eh 12:52 celeron55 @everyone (how does one discord) 12:52 celeron55 nope, doesn't work 12:52 celeron55 well ideally the bridge would convert the notice to something useful 12:54 MTDiscord We disabled Randoms being able to spam everyone 12:55 Krock @everyone (I must test it too) 12:56 Krock celeron55: another idea: have the member entries as a meeting discussion. 12:56 Krock the proportions would be heavily shifted towards core devs, though. but you'd get more feedback at once 12:57 celeron55 that could work, but personally i kind of hate scheduled meetings in hobby projects. it feels like work 12:58 celeron55 the forum style either on the forum or on GH discussions fits better. one can just slap the question there, and come look at the answers later 12:59 celeron55 we could of course have a meta-repo where questions could be added as issues. that way they would be readable to the public 13:00 Krock there's almost no other occasion where there's a few people online at the same time. This chat used to be more active a few years ago (might be only my impression), but nowdays it's difficult to even get a few people ready to meet up every two weeks or month 13:00 sfan5 github discussions can be enabled on a repo and be used like a forum btw 13:00 sfan5 (public) 13:00 Krock oh right. I've also seen something like that used as a Q&A 13:02 celeron55 that does still bring in the vendor lock-in (but one can hope that some competitor will provide a migration tool). it's fine for non-persistent stuff i think 13:04 MTDiscord sfan5, the fix is not layout specific; it handles both QWERTY and Dvorak layouts, and that is enough to convince me it handles any common layout. 13:06 MTDiscord I have a US QWERTY laptop keyboard. I do not have a German keyboard. The consequence is that there are certain scancodes that I cannot test, because I have no key that generates them. 13:07 MTDiscord I do, thankfully, have a numpad on this laptop, so I shall get that working next. 13:09 MTDiscord The Windows documentation has a picture showing how scancodes are allotted to the physical keys, but they seem to be off-by-one in some places. In other places my keys are simply not laid out the same way. SDL lists scancodes by button names, not by button position, so determining which button name corresponds to which position is an annoying trial and error task. 13:10 MTDiscord (Just to reiterate, the SDL scancodes and the Windows scancodes are different. SDL ordered them by button name, e.g. A-Z are ascending in order, whereas Windows ordered them according to position on a US QWERTY keyboard, so ASDFGH are in ascending order and so on.) 13:14 MTDiscord The one potential issue with the fix is that I opted (for now, anyway) to query Windows for the keyboard state rather than trying to manually track it, which looked like it would require some understanding of Windows' internal implementation detail, and some bitops. Because of this, there's a period between the SDL key event and the Windows API call where the keyboard state may change. In my testing this is not noticeable, but I have 13:14 MTDiscord a good laptop and I wasn't experiencing any sluggish rendering. I'm still concerned that the behavior could catch someone off guard someday. 13:15 MTDiscord You might press shift-3 and then release the shift key first, and Windows would not detect that the shift key was down when it tries to interpret the keypress, so you'd get the wrong character. 13:16 sfan5 okay wait, it's a windows only fix? 13:25 MTDiscord Yep, for starters. I think I said this before but I'm calling the Windows API behind SDL's back like you said wouldn't work. 13:25 MTDiscord I did make sure to pass a flag so that the call has no side-effects in the Windows keyboard state (which it otherwise would). 13:26 MTDiscord Thus, I dodged one bullet, but I don't know what else is going to break. So far everything feels quite normal to me as a user, but it's the edge cases I'm worried about. 13:26 MTDiscord You know a lot more about this than I do so you probably saw something coming I'm not aware of. 13:28 MTDiscord The X11 keyboard API looks slightly simpler, and I know Linux better, so I saved it for last. But it sounds like for completeness I also have to handle Wayland. 13:29 MTDiscord To be fair, you didn't say it wouldn't work; I think you said something about not being able to simply do it. 13:30 sfan5 i don't have a technical comment but I think putting this much effort into an os-specific workaround may not be worth it 13:31 Krock let's just bundle SDL3 and call it a day /s 13:33 MTDiscord It's a horrifying amount of effort considering SDL should be doing it for us, but it's my decision to work on it. It's up to the core team whether to review it and accept it though. 13:46 Krock if it's just for key input handling, then Irrlicht already got us covered. but I don't know whether that and SDL could coexist 13:59 Krock --> Meeting in 1 hour from now 14:08 sfan5 I will be absent 14:11 Krock that's unfortunate but thanks for letting us know. By the way, we could as well move the meeting again. The last change was requested by srifqi, who is rather inactive in terms of meetings 14:21 [MTMatrix] RE Krock chat more active a few years ago: I guess several people started using Discord or Matrix instead of IRC. We're here, you simply can't see us 14:23 Krock @Zughy That means another channel is filled with core developer discussion? 14:27 nrz Celeron your @ notifies us on discord app 14:28 MTDiscord @ person generally works, at every one does not 14:56 MTDiscord Which scancodes are missing? 14:57 Krock Meeting in 3 minutes. Pinging people who reacted to the meeting post: @Zughy @luatic. Others: Desour nrz. 14:57 Krock We'll be going through the milestone and I'll take meeting notes as we go on 15:00 Krock > #14545 15:00 ShadowBot https://github.com/minetest/minetest/issues/14545 -- SDL: Some keybinds broken due to missing character lookup 15:00 Krock (there is additional talk before this meeting concerning this issue) 15:02 Krock also discussed a few days ago here: https://irc.minetest.net/minetest-dev/2024-07-27#i_6187958 15:03 Krock from what I can see this is the final blocker for a proper release, and then continue with a flood of PR merges 15:05 Krock options: https://irc.minetest.net/minetest-dev/2024-07-27#i_6188330 15:05 Krock shall I open a poll regarding this issue, if so, where? 15:06 Krock a few people stated their preferences but having this unanswered will eventually lead to a feature freeze until a fix is implemented that hopefully does not cause any regression 15:07 Krock opinions? 15:08 MTDiscord from the issues reported so far (primarily "/") i don't think this bug has the severity of a blocker 15:12 Desour I'm for #14894 15:12 ShadowBot https://github.com/minetest/minetest/issues/14894 -- Work around the SDL keybinding issue in a very hacky manner by grorp 15:13 Krock Desour: That might solve this particular issue for all QWERTZ keyboard layouts, but none other 15:13 MTDiscord my minor concern with that hack is that it could annoy people who are sneaking and want to switch to the n-th item on a non-german keyboard 15:14 celeron55 the correct term for this keyboard layout is something like "latin keyboard". many more than just german is like this 15:15 Krock French does not seem to be affected, Spanish is "fixed" by this workaround 15:15 celeron55 finnish/swedish/norwegian falls into this class of layouts 15:15 MTDiscord celeron55: this may annoy users on all keyboard layouts where 7 does not become / if shift is pressed 15:16 MTDiscord which i believe probably includes some non-german latin ones. in other words, german is the only layout where i know this to be correct. 15:16 celeron55 i support just not fixing it and designing a new shortcut for the chat command key, but i suspectm any users would be extremely annoyed 15:16 MTDiscord I wonder whether you can conditionally activate the workaround based on whether the keyboard has a "/" key that does not require pressing shift 15:16 Krock checked a random keyboard layout. http://www.kbdlayout.info/kbdbulg Bulgarian needs Shift + 8. 15:17 celeron55 you can find giant lists of layouts like this https://keyshorts.com/blogs/blog/44712961-how-to-identify-laptop-keyboard-localization 15:18 Krock oh that's nice. thanks. 15:19 Krock dedicated key is most common, followed by Shift + 7. 15:20 celeron55 shift+7 seems to be a nordic + eastern european + german thing, but there's also portugese 15:21 MTDiscord y5nw: well, there is SDLK_SLASH. i assume a dedicated key would produce that. so we would know that there is a dedicated key if it has been pressed 🙃 15:21 celeron55 enable the hack by default as a setting and if SDLK_SLASH is pressed, disable the setting immediately? :D 15:22 Krock dear god 15:22 celeron55 frankly, it would work 15:22 Krock that's how heisenbugs are born. occur once, and then you try to reproduce it and it stops working until you notice that you have to clear the cache 15:22 MTDiscord I was thinking about SDL_GetScancodeFromKey(SDLK_SLASH) != SDL_SCANCODE_UNKNOWN 15:23 MTDiscord ooh there is a reverse scancode from keycode? yeah that might work. 15:23 Krock @y5nw. good find. I'd be interested in seeing the outcome of this. 15:23 celeron55 it think the conditional hack is a reasonable solution if something like that works as the conditional 15:23 MTDiscord agreed 15:25 MTDiscord compiling 15:26 ROllerozxa re: reverse scancode from keycode - how would SDL handle that if I have a full sized keyboard with dedicated / on numpad vs a keyboard without numpad? 15:26 Krock was about to leave a comment for that in #14894 so I'll wait a few minutes for your results 15:26 ShadowBot https://github.com/minetest/minetest/issues/14894 -- Work around the SDL keybinding issue in a very hacky manner by grorp 15:26 Krock ROllerozxa: c'mon I thought we finally had a good solution 15:27 Desour my german keyboard does have a physical / on the numpad 15:27 ROllerozxa lol 15:27 Desour but it doesn't look like "/" 15:27 MTDiscord tried real quick, doesn't seem to work 15:27 MTDiscord hmm maybe i made a mistake? 15:28 Krock @luatic just print the function output to stdout to figure out 15:29 MTDiscord yeah i did that 15:29 Krock > SDL_SCANCODE_SLASH = 56, 15:29 MTDiscord it prints 0 (SDL_SCANCODE_UNKNOWN) correctly for me 15:29 MTDiscord so i probably made a mistake 15:30 Krock even if you use setxkbmap us ? 15:31 MTDiscord i'm trying it on my german layout at the moment. the value of 0 is correct and as expected, but i still don't get chat to open when i press shift + 7. 15:32 Desour make sure you didn't change the keybind setting 15:32 celeron55 the numpad slash is probably a different scancode because it's also on US keyboards 15:33 MTDiscord is the numpad slash a slash and not a division? 15:33 celeron55 in X11 it's KP_Divide or something 15:33 MTDiscord SDLK_KP_DIVIDE 15:33 ROllerozxa ah good, they're separate 15:34 Noisytoot Is it possible to bind multiple keys to the same thing (for example the ordinary / and numpad /)? 15:34 MTDiscord Desour: it does appear i changed it, though i don't remember that 🤔 15:34 Krock Noisytoot: with irrlicht's code: yes. with SDL: no 15:35 Krock that is as long the keys produce the same printable character 15:35 Desour KPDV, makes KP_Divide, according to my xkeymap 15:36 Desour Krock: I thought our settings don't allow that 15:36 MTDiscord yeah they don't 15:36 Desour ah nevermind, misread question 15:36 Krock Desour: irrlicht's input handling does by printed characters, that's why I can open the commands with Shift+7 and the numpad divide 15:37 Desour ah, thx 15:37 Krock same principle for + and - for range select 15:37 MTDiscord shouldn't opening the console give me a "/" in it? 15:37 Krock it should, yes. 15:37 Krock unless you used F10. there's another gatekeeper to prevent the '/' input 15:37 MTDiscord luatic: Oops, should be == SDL_SCANCODE_UNKNOWN, not != 15:38 MTDiscord y5nw: i changed that, don't worry. i had F10 keybinding previously, that was the issue. 15:38 MTDiscord but now when i use / i get no / in the console 🙃 15:39 Krock I suppose you're not manipulating the event to fake the / literal input 15:39 MTDiscord i am 15:39 MTDiscord that's how console opens in the first place 15:41 MTDiscord I sent a PR to grorp for now 15:41 Krock does it also work as expected when releasing the key? 15:42 Desour the thing it binds to should open the console with a pre-inserted /. and other text input should work over the other event type 15:43 y5nw grorp's PR seems to change both the key press and releasing events 15:45 Krock '/' is likely inserted by GUIChatConsole::OnEvent 15:45 Krock guiChatConsole.cpp L658 15:45 MTDiscord Krock: i assume has_char in that function is determined wrongly after the fix 15:46 MTDiscord s/fix/hack 15:46 Krock it is only reading the PressedDown=1 even, though. 15:46 Krock *event 15:47 MTDiscord Krock: see line 442. there's a hack to combat something MacOS does. 15:47 Krock should be OK with changes similar to what grorp did 15:47 y5nw Krock: that seems to be for when the console is already opened though. I think the handler for opening the console is in the client input handler 15:48 Krock game.cpp L2086 15:48 Krock it's passed as a separate argument 15:52 Desour oh this is funny, the chat console doesn't handle its hardcoded keybinds if the key event has a char, didn't know x) 15:53 MTDiscord nvm i bound console, not command 15:53 MTDiscord sorry for the confusion 15:54 Krock no worries. I hope we can get somewhere with this 15:56 MTDiscord well y5nw has sent their PR to grorp (https://github.com/grorp/minetest/pull/12/) so that should be fine 15:56 Desour if we merge this hack, should we also handle other common layouts? 15:57 Desour e.g. according to https://irc.minetest.net/minetest-dev/2024-07-27#i_6188385 , shift = is + on us layout 15:57 Desour shift + = = + 15:57 y5nw Isn't = already the default binding for increasing view range? 15:58 MTDiscord i think + is the default binding for increasing view range 15:59 Desour defaultsettings.cpp says it's + 16:00 Desour thinking of it, using "/" to open command is useful, because it saves one keypress. for + on the other hand, it has no reason to be bound to the "+" char 16:00 Noisytoot = works the same as + (shift + =) for me (with 5.7.0) 16:01 Krock I'll be away for about 30 minutes. Sorry. Please continue. I'll read the logs and complete the meeting notes. 16:01 celeron55 the point of the "/" shortcut is to be able to just type the command, without thinking about opening the chat console, and it takes advantage of the fact that there's no other reason to press "/" 16:06 MTDiscord i have an interesting hack idea 16:07 MTDiscord it is claimed in https://discourse.libsdl.org/t/scancode-vs-keycode/32860/3 that SDL_TEXTINPUT is emitted even if SDL_StartTextInput was not called and this seems to be the case. we should be able to get correct char codes that way. 16:09 MTDiscord nevermind, ignore this 16:20 [MTMatrix] Who actually uses that shortcut? Like, I know it exists and I've never used it 16:22 MTDiscord my muscle memory is to open chat with T to type commands despite knowing of the existence of / 16:22 celeron55 i made it for myself back then so it's no surprise i use it 16:22 [MTMatrix] ^ (luatic) 16:24 Desour I used to use it 16:26 Krock back. I use Shift + 7 ('/') because it inputs the slash and I need both hands on the keyboard anyway, thus it's the 2nd most efficient way (most efficient being the numpad). 16:27 Noisytoot I use / often 16:27 Krock actually rebinding it to any other key would be possible too, which is then equivalent to the numpad situation. 16:29 Krock will merge #14904 in 10 minutes 16:29 ShadowBot https://github.com/minetest/minetest/issues/14904 -- Take screenshot from back buffer when using double buffering by fgaz 16:30 Krock any additional remarks/questions regarding the 5.9.0 milestone? 16:31 MTDiscord status of #13987 16:31 ShadowBot https://github.com/minetest/minetest/issues/13987 -- [pls do not squash :3] Allow limiting object observers by appgurueu 16:31 Krock I frankly don't want to have this in 5.9.0 16:32 Krock but as one of the first PRs to make it into the next dev version 16:33 Krock and I know Zughly will somewhat dislike what I just said 16:33 Krock -l 16:35 MTDiscord i don't see a very significant benefit to delaying it 16:35 MTDiscord does it really get significantly more testing if it sits in the dev version for half a year? 16:35 Krock In the next meeting point I would've liked to discuss pgimeno's idea of faster release cycles 16:35 MTDiscord ultimately i suppose the question is: what is the chance of introducing "last minute" regressions, and what is the chance that delaying this for 5.10 can guard against that? 16:37 Krock I will check that in the case the feature is not used at all, that the code paths touch as few code areas as possible. That's possibly a way to argue about its risks. 16:37 MTDiscord thanks 16:38 Krock PRs are by far less often tested than dev versions. Barely anyone wants to set up a dev env to contribute to Minetest. Instead, they'd like to test the new features directly from pre-built binaries 16:39 Krock those are distributed for Windows via the forums, or for several distros on their own servers. 16:39 MTDiscord well, this PR was at least previously tested on a popular server which had a use case for it (CTF) 16:39 Krock merging 14904 ... 16:41 Krock right. thanks for reminding. 16:42 Krock I'll go through the PR after the meeting and let you know by review. 16:43 MTDiscord great. i trust your judgment on this matter. if you advise caution, i'm fine with postponing. 16:43 MTDiscord feel free to adjust the milestone (or not) after your review. 16:43 Krock thank you. 16:43 Krock > Future development cycle idea by pgimeno. Almost permanent feature freeze. https://irc.minetest.net/minetest-dev/2024-07-17#i_6185892 16:45 Krock shall I open a poll for this to see what contributors think about that? I'd likely post it on the forums so that contributors have access to it. 16:45 MTDiscord i'm pro faster release cycles. not so sure about the "batch feature PRs" part of the proposal. 16:45 Krock it'll have to have two approvals, after all. 16:46 Krock merge conflicts were also brought up in the discussion back then 16:46 MTDiscord Krock: the problem with the forums is that all forum users have access to those. how would you make sure only contributors vote? 16:48 Krock @luatic I'd have to check whether there's an option to set the access on GitHub properly 16:48 Krock currently I am only aware of internal discussions and such where every user has access 16:49 grorp merged y5nw's improvement into #14894 16:49 ShadowBot https://github.com/minetest/minetest/issues/14894 -- Work around the SDL keybinding issue in a very hacky manner by grorp 16:50 Krock there's no access settings for the "Discussions" checkbox (project settings) 16:50 MTDiscord i believe celeron might have to configure that 16:50 MTDiscord cant you just make a github issue with the poll and limit commenters to contributors? 16:50 Krock I can check it live on a personal project of mine 16:52 Krock @wsor4035 The "github polls" search results lead to the Discussions page, which has no such setting 16:52 MTDiscord nevermind, thats only people that are in the org, rather than people who have contributed to it 16:52 Krock there's project and organization-specific discussions 16:53 MTDiscord well. what should work is a github issue tagged discussion. then let people voice their opinions. needs to be evaluated manually, but that should be a matter of 5 mins. 16:53 Krock one for everyone, and one for members only 16:54 Krock issue-based makes sense. I'll set up an issue - unless someone else would like to take care of this? 16:55 Krock (makes sense as long external contributions are very rare. otherwise we'd have to consider another option) 16:56 Krock Any other topics? 16:57 Krock e.g. #14894 needs reviews 16:57 ShadowBot https://github.com/minetest/minetest/issues/14894 -- Work around the SDL keybinding issue in a very hacky manner by grorp 16:58 MTDiscord celeron has been asking for opinions on making cx384 a core dev recently 16:58 MTDiscord so if anyone else wants to share their opinion feel free to 16:59 Krock (IRC logs: a few hours ago) 17:03 celeron55 re. pgimeno's release cycle proposal: it seems to me like it could work. coordinating the switch to it (and possibly away from it) could take time and effort though 17:04 celeron55 it doesn't differ a lot from the development branch concept that's already in the development rules/guidelines though, and that would be more familiar to most 17:05 Desour +1 on cx384 becoming coredev 17:06 celeron55 i mean, compared to pgimeno's proposal, PRs wouldn't be left "ready to merge" but they would be merged, but instead of into master, the merge would happen into the development branch, and then the development branch would be merged into master after each release 17:06 Krock celeron55: the difference will be that 1 month long feature freezes will become normal 17:06 Desour tbh, when I read pgimeno's proposal the first time, and also most of the other times, I thought it was meant to be a sarcastic joke 17:06 MTDiscord Krock: btw, you're pinging a member named "C" on the Discord side of the bridge 17:07 MTDiscord (are you writing celeron with an uppercase C?) 17:07 Desour having a separate development branch, on the other hand, would make sense 17:08 celeron55 it's described here https://dev.minetest.net/Git_Guidelines#Upstream_branch_rules 17:08 Krock @luatic That must be a bug in the bridge bot. I checked the logs and there are no special characters 17:08 celeron55 if this would be followed, the proposal essentially is to just stop the feature freeze for only the moment when the dev branch is merged into master, and then start it immediately again 17:09 Desour afaik rust uses a similar dev cycle, btw 17:09 celeron55 so, all i'm really saying is, we're already set up for it. you can start at any time 17:10 Krock I think that a separate branch causes unnecessary work and makes the history nonlinear 17:11 celeron55 but it makes the merge conflicts not clump up 17:11 Desour so, if there'd be a feature in the dev branch that causes a regression, we'd not merge that one, right? how would this be different from just reverting that feature from master 17:11 Krock in that case, PRs would have to target the dev branch and not master so that there's no accidental squash & merge happening there 17:12 Krock unless everyone is perfectly cautious 17:13 Krock also fixes that happen in the master branch during feature freeze might not or improperly apply to the dev branch 17:14 Krock rebase/merge conflicts are bound to happen somewhere 17:15 celeron55 there are reasons the dev branch has been usually skipped: 1) it makes no sense when not that many people are working at once, 2) it's generally simpler and not as much can go wrong, and people have to be less aware of all the details 17:16 celeron55 but when many people are working at once and they can be made aware of the more complex workflow, then it can make sense 17:16 celeron55 are you saying pgimeno's proposal of (as i understand it) essentially tagging PRs to be merged after the feature freeze and then doing it at once, would be less error prone? 17:17 celeron55 i don't like the fact that the interaction and conflicts between the PRs won't show up until the day of the delayed merge. but i don't know how bad that would be in practice 17:18 Krock I suppose it's more error-prone. The case in feature freeze that I mentioned above might only affect a few dozen oflines 17:19 Krock difference being that a maintainer needs to keep the overview and knowledge to properly resolve those issues, whereas in the 1-branch approach, it's the PR author who's responsible for making it compatible 17:21 Krock note: the tagging of the PR's would likely be the ">= 2 approvals" label 17:24 MTDiscord Wouldn't removing the dev branch also mean that features that are known to be functional but not necessarily performant might end up in the main branch before they can be fully tested, I think there's some merit to having a dev branch. Even if nobody but the developers pull from it, it still serves the purpose of segmenting out features that are tested from features that are working but may not necessarily be ready for general use. 17:25 Desour non ready features are usually just not merged 17:26 MTDiscord Then how would you collaborate I'm getting them ready, or is the burden of optimization solely on the person making the pr request? 17:26 MTDiscord there are ways for multiple people to collaborate on a PR, usually by sending PRs to the PR author 17:27 MTDiscord Fair enough, sorry for the confusion then. I guess I'm not quite used to open source development. 17:27 Krock or adopt someone's PR if the original author is no longer interested in continuing it 17:29 Krock Saved the meeting notes for now. Reviewing the observers PR. 17:40 Krock I'll pause the dev branch topic for a moment. Probably it'll result in a poll to see what contributors prefer. Thank you for participating. 17:41 MTDiscord thank you for organising. 17:53 MTDiscord One is the umlaut key that is next to left shift. US keyboards don’t have it. 18:01 [MTMatrix] Honestly I find a bit absurd how the thing that is holding us back from releasing is the key to open the chat with a / already in it 18:03 MTDiscord I have never seen that key 18:04 [MTMatrix] And we're risking to delay the entity feature yet again; yet beware the chat command key. It very looks like devs prioritising devs stuff, ignoring the userbase 18:08 [MTMatrix] It's already happened in the past that we introduced a few regressions without even noticing. Regressions imho way worse of a key that requires hacky workarounds. E.g. overriding entities speed to 0, that behaves differently in 5.4 compared to 5.8. As a modder, THAT should be a priority imho, as it can literally fuck up how a game is designed 18:10 MTDiscord I’m working on this at no benefit to myself because I think it’s irresponsible to release with a known bug. And I’m not a core dev so the development is not using core dev time except for review. 18:18 Desour here's an alternative proposal for faster release times: https://gist.github.com/Desour/9c829d686de637413e94e23a7a49bd1f 18:21 MTDiscord In case it's not clear, the keyboard issue is a regression. 18:22 celeron55 if that was being followed in this cycle, sdl2 would have been dropped off the release once the keyboard issue was found? 18:22 Desour we would've switched it off 18:22 MTDiscord Dropping SDL2 seems to me like the most reasonable thing to do, but I think that was off the table this time? 18:23 Desour could also add the option to not fix a regression, but ship it, or hackily fix it a bit 18:23 Desour (which I kinda understand as "fixing" it. if we're ok to ship it, we declare it to not an issue anymore) 18:25 celeron55 sdl2 isn't really a user-facing feature, but it is the base future things should be built upon which makes it important. not using it risks adding technical debt. working around the issue might add less technical debt 18:28 celeron55 do you think it's feasible to find out beforehand how pissed off users are if the release is made with sdl2 with no workarounds? 18:30 celeron55 like, just set the default keymap_cmd to KEY_KEY_O (or something like that) and hope for the best 18:30 Desour (added exception to (4)) 18:31 celeron55 i, as apparently the only one here actually using the feature, wouldn't be pissed 18:32 celeron55 there's a chance it'll cause a flood of requests and the workaround has to be added to the next release then. or it might not. we know the workaround can be added and works fine enough, so it's not a dead end 18:32 Desour celeron55: pissed of users usually don't complain (at least I don't when I'm pissed off), because the inhibition threshold to do so is high: you have to register somewhere and be the unpolite user screaming around 18:34 celeron55 one argument is that it's an anti-feature and key combinations shouldn't be used until there's an actual feature allowing them 18:34 celeron55 and even then when there's one, none of the default keybinds should probably use it 18:35 celeron55 yes, i'm saying i may not necessarily should have added the feature in the first place 18:35 celeron55 but it was accidental, as irrlicht made it so easy 18:37 celeron55 so, if someone asks me what to do, my answer is: just ship it. with or without workaround. throw the dice if need be, and prepare to switch in the next release 18:37 Desour as someone who has used the feature, it was quite annoying when I switched to SDL and the bind didn't work. but one gets used to it, so releasing with the bug would be ok, imo. but as we have the hacky fix ready now, why not merge it? 18:39 Mantar I use the / key all the time, but it's a dedicated key for me so I suppose I'll be fine either way. 18:40 Mantar and yeah if there's a fix for a regression, even if it's a bit hacky, I think that's better than shipping with a known regression 18:43 Desour btw. another thing that happened when I switched to SDL is that my mouse was faster, so I had to change the setting. (maybe that's because of my weird config. I'm setting a matrix with xinput, iirc); might be worth noting in some release note that users might have to change mouse sens setting 18:47 MTDiscord Speaking of which, the game is unplayable on WSL with default settings due to a mouse issue. I haven't found a way to fix it. 18:48 MTDiscord I had the same issue trying to play on a virtual machine. 18:48 Krock @josiah_wi missing mouse re-positioning, or is it due to subpixel inaccuracies? 18:49 MTDiscord Krock: I think it's related to mouse repositioning 18:49 Krock Wine had such issue too, about 6 months ago 18:49 sfan5 I can't play minetest over vnc either 18:49 sfan5 it's the relativ mouse movement change 18:50 Krock if VNC does not work, does running it though ssh -X work? 18:50 Krock (assuming that there's a x11-compatible layer) 18:53 rubenwardy #13987 is a feature and should not be on the 5.9.0 milestone 18:53 ShadowBot https://github.com/minetest/minetest/issues/13987 -- [pls do not squash :3] Allow limiting object observers by appgurueu 18:54 Desour playing minetest with a graphics tablet is also... interesting 18:54 Desour minetest as of now doesn't use relative mouse movements, see updateCameraOrientation 18:55 Desour in game.cpp 18:55 rubenwardy Although, if we don't do 5.9.0 for two weeks after merging #13987 you could consider the freeze to be stopped and restarted 18:55 ShadowBot https://github.com/minetest/minetest/issues/13987 -- [pls do not squash :3] Allow limiting object observers by appgurueu 18:55 rubenwardy I don't think it's a blocker feature though 19:00 rubenwardy So sounds like pgimeno's idea is essentially a pipeline approach. We'd release (say) monthly and have month long feature freezes. The master branch will be stuff under freeze for the next release and there will be a dev branch with stuff being added for the release after that 19:04 rubenwardy I've done something similar at work, except instead of a feature it's a beta release 19:08 rubenwardy s/feature/freeze 19:20 sfan5 Krock: opengl does not work through x11 forwarding 19:20 sfan5 at least I'm pretty sure 19:25 Krock sfan5: I haven't tried it either. The idea is interesting, though. 19:26 Krock btw, if another meeting time would fit better (in general), then we could adjust accordingly. 19:27 Krock e.g. adjusting towards European evenings; but risking to cut off eastern contributors 19:32 Krock let me know if there's such preference, or set up a poll so that our meetings can become more effective in the future 19:32 Krock s/effective/efficient 19:53 MTDiscord Krock, I don't know the reason, but the camera moves in a different direction that the mouse. I tried changing camera sensitivity and that setting seemed to work, but the direction was still off. 19:54 MTDiscord After more experimentation, I have a hunch that part of the effect is a very delayed response to changes in mouse direction. If you move the mouse left, and then right, the camera will lag behind by a second or more. 19:55 MTDiscord It's predictable enough that I might be able to learn to control the camera the way I want with practice, but it's very unintuitive, and it's impossible to move the camera a short distance because the camera starts moving with the mouse, but finishes later than the mouse, which effectively extends the distance over which the camera moves. 19:56 Krock #13258 19:56 ShadowBot https://github.com/minetest/minetest/issues/13258 -- Severe lag on Apple Silicon macOS when looking around while moving 19:56 Krock nvm. you're not the one who mentioned macOS 19:56 MTDiscord I'm not having any lag. I have good frame rate. 19:57 MTDiscord I could look into making a screen capture of the issue, but it mostly just looks like someone wildly moving the mouse in random directions. 19:57 Krock so the input queue is not stalling, but rather hanging unpredictably in some sort of queue 19:58 MTDiscord Yeah, it seems like that. 19:58 Krock *not stalling = blocking the thread, like mutex lock waits in OnEvent() callbacks 19:58 MTDiscord At first I mistook it for my mouse sensitivity being insanely high. 20:02 MTDiscord The player can move around and do things, which I think is evidence that the thread is not blocked.