| Time |
Nick |
Message |
| 02:23 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> I have all the code done and I spent some time polishing it and doing the necessary ifdefs. |
| 02:25 |
MTDiscord |
<josiah_wi> 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. |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:29 |
|
MTDiscord joined #minetest-dev |
| 04:49 |
|
fluxionary joined #minetest-dev |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:47 |
|
Warr1024 joined #minetest-dev |
| 09:29 |
sfan5 |
so the fix is layout-specific? |
| 09:50 |
|
Desour joined #minetest-dev |
| 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] |
<grorp> +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] |
<grorp> 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:42 |
|
cx384 joined #minetest-dev |
| 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 |
<wsor4035> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> I do, thankfully, have a numpad on this laptop, so I shall get that working next. |
| 13:09 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> (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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> You know a lot more about this than I do so you probably saw something coming I'm not aware of. |
| 13:28 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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:47 |
|
Desour joined #minetest-dev |
| 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] |
<Zughy> 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 |
<wsor4035> @ person generally works, at every one does not |
| 14:56 |
MTDiscord |
<herowl> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> celeron55: this may annoy users on all keyboard layouts where 7 does not become / if shift is pressed |
| 15:16 |
MTDiscord |
<luatic> 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 |
<y5nw> 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 |
<luatic> 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 |
<y5nw> I was thinking about SDL_GetScancodeFromKey(SDLK_SLASH) != SDL_SCANCODE_UNKNOWN |
| 15:23 |
MTDiscord |
<luatic> 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 |
<luatic> agreed |
| 15:25 |
MTDiscord |
<luatic> 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 |
<luatic> tried real quick, doesn't seem to work |
| 15:27 |
MTDiscord |
<luatic> hmm maybe i made a mistake? |
| 15:28 |
Krock |
@luatic just print the function output to stdout to figure out |
| 15:29 |
MTDiscord |
<luatic> yeah i did that |
| 15:29 |
Krock |
> SDL_SCANCODE_SLASH = 56, |
| 15:29 |
MTDiscord |
<luatic> it prints 0 (SDL_SCANCODE_UNKNOWN) correctly for me |
| 15:29 |
MTDiscord |
<luatic> so i probably made a mistake |
| 15:30 |
Krock |
even if you use setxkbmap us ? |
| 15:31 |
MTDiscord |
<luatic> 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 |
<luatic> is the numpad slash a slash and not a division? |
| 15:33 |
celeron55 |
in X11 it's KP_Divide or something |
| 15:33 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<y5nw> luatic: Oops, should be == SDL_SCANCODE_UNKNOWN, not != |
| 15:38 |
MTDiscord |
<luatic> y5nw: i changed that, don't worry. i had F10 keybinding previously, that was the issue. |
| 15:38 |
MTDiscord |
<luatic> 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 |
<luatic> i am |
| 15:39 |
MTDiscord |
<luatic> that's how console opens in the first place |
| 15:41 |
MTDiscord |
<y5nw> 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 joined #minetest-dev |
| 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 |
<luatic> Krock: i assume has_char in that function is determined wrongly after the fix |
| 15:46 |
MTDiscord |
<luatic> s/fix/hack |
| 15:46 |
Krock |
it is only reading the PressedDown=1 even, though. |
| 15:46 |
Krock |
*event |
| 15:47 |
MTDiscord |
<luatic> 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 |
<luatic> nvm i bound console, not command |
| 15:53 |
MTDiscord |
<luatic> sorry for the confusion |
| 15:54 |
Krock |
no worries. I hope we can get somewhere with this |
| 15:56 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> i have an interesting hack idea |
| 16:07 |
MTDiscord |
<luatic> 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:07 |
|
fluxionary joined #minetest-dev |
| 16:09 |
MTDiscord |
<luatic> nevermind, ignore this |
| 16:20 |
[MTMatrix] |
<Zughy> Who actually uses that shortcut? Like, I know it exists and I've never used it |
| 16:22 |
MTDiscord |
<luatic> 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] |
<Zughy> ^ (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 |
<luatic> 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 |
<luatic> i don't see a very significant benefit to delaying it |
| 16:35 |
MTDiscord |
<luatic> does it really get significantly more testing if it sits in the dev version for half a year? |
| 16:35 |
|
grorp joined #minetest-dev |
| 16:35 |
Krock |
In the next meeting point I would've liked to discuss pgimeno's idea of faster release cycles |
| 16:35 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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:42 |
|
luk3yx joined #minetest-dev |
| 16:43 |
MTDiscord |
<luatic> great. i trust your judgment on this matter. if you advise caution, i'm fine with postponing. |
| 16:43 |
MTDiscord |
<luatic> feel free to adjust the milestone (or not) after your review. |
| 16:43 |
|
Noisytoot_ joined #minetest-dev |
| 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 |
<luatic> 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 |
<luatic> 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 |
|
panwolfram joined #minetest-dev |
| 16:48 |
|
sfan5 joined #minetest-dev |
| 16:48 |
|
hifi joined #minetest-dev |
| 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 |
<luatic> i believe celeron might have to configure that |
| 16:50 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> 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 |
<luatic> 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 |
<luatic> celeron has been asking for opinions on making cx384 a core dev recently |
| 16:58 |
MTDiscord |
<luatic> 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 |
<luatic> Krock: btw, you're pinging a member named "C" on the Discord side of the bridge |
| 17:07 |
MTDiscord |
<luatic> (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 |
<redundantcc> 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 |
<redundantcc> 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 |
<luatic> there are ways for multiple people to collaborate on a PR, usually by sending PRs to the PR author |
| 17:27 |
MTDiscord |
<redundantcc> 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 |
<luatic> thank you for organising. |
| 17:53 |
MTDiscord |
<josiah_wi> One is the umlaut key that is next to left shift. US keyboards don’t have it. |
| 18:01 |
[MTMatrix] |
<Zughy> 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 |
<herowl> I have never seen that key |
| 18:04 |
[MTMatrix] |
<Zughy> 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] |
<Zughy> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<y5nw> 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:48 |
|
YuGiOhJCJ joined #minetest-dev |
| 19:53 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> I'm not having any lag. I have good frame rate. |
| 19:57 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> Yeah, it seems like that. |
| 19:58 |
Krock |
*not stalling = blocking the thread, like mutex lock waits in OnEvent() callbacks |
| 19:58 |
MTDiscord |
<josiah_wi> At first I mistook it for my mouse sensitivity being insanely high. |
| 20:02 |
MTDiscord |
<josiah_wi> The player can move around and do things, which I think is evidence that the thread is not blocked. |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:39 |
|
fluxionary joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
