| Time |
Nick |
Message |
| 00:24 |
|
SFENCE joined #minetest-dev |
| 00:43 |
|
SFENCE joined #minetest-dev |
| 00:52 |
|
hwpplayer1 joined #minetest-dev |
| 00:58 |
|
hwpplayer1 joined #minetest-dev |
| 01:05 |
|
SFENCE joined #minetest-dev |
| 01:25 |
|
hwpplayer1 joined #minetest-dev |
| 01:26 |
|
SFENCE joined #minetest-dev |
| 01:58 |
|
SFENCE joined #minetest-dev |
| 02:06 |
|
SFENCE joined #minetest-dev |
| 02:16 |
|
hwpplayer1 joined #minetest-dev |
| 02:40 |
|
SFENCE joined #minetest-dev |
| 02:44 |
|
v-rob joined #minetest-dev |
| 03:00 |
|
SFENCE joined #minetest-dev |
| 03:24 |
|
SFENCE joined #minetest-dev |
| 03:42 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:01 |
|
SFENCE joined #minetest-dev |
| 04:03 |
|
SFENCE joined #minetest-dev |
| 05:16 |
|
SFENCE joined #minetest-dev |
| 05:22 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:22 |
|
ivanbu joined #minetest-dev |
| 05:50 |
|
SFENCE joined #minetest-dev |
| 06:20 |
|
v-rob joined #minetest-dev |
| 06:26 |
|
SFENCE joined #minetest-dev |
| 06:31 |
|
SFENCE joined #minetest-dev |
| 06:56 |
|
SFENCE joined #minetest-dev |
| 07:23 |
|
SFENCE joined #minetest-dev |
| 07:23 |
|
SFENCE joined #minetest-dev |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:47 |
|
Warr1024 joined #minetest-dev |
| 09:56 |
sfan5 |
huh |
| 09:57 |
sfan5 |
i need to stop before I surpass c55 |
| 10:03 |
|
chmodsagtwas joined #minetest-dev |
| 10:08 |
chmodsagtwas |
According to https://dev.minetest.net/Code_style_guidelines, one should never put an opening brace on the same line as an if-statement ("Putting the body of an if statement on the same line as the condition is strictly prohibited."), but what about else? I've seen both "else {" and "else <newline> {" in minetest-sources... |
| 10:09 |
[MatrxMT] |
<Zughy> sfan55 |
| 10:10 |
sfan5 |
it is talking about the body, not the brace |
| 10:10 |
sfan5 |
putting the brace on the same line is actually encouraged if you look here https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces |
| 10:11 |
chmodsagtwas |
nevermind, my bad. Thanks for clarifying though. |
| 10:37 |
|
Desour joined #minetest-dev |
| 12:37 |
|
Lupercus joined #minetest-dev |
| 12:53 |
sfan5 |
Desour: so i investigated drawing order and solid stuff is indeed drawn front-to-back |
| 12:54 |
sfan5 |
it just happens that lots of irrelevant stuff is drawn first before we get to the stone wall that's covering half the viewport |
| 12:54 |
sfan5 |
if that could be improved via some heuristic I think that could save some gpu work |
| 13:04 |
sfan5 |
i guess prioritizing whatever buffer group draws the most nodes (not vertices) would work |
| 13:10 |
Desour |
sfan5: we draw block chunk meshes first that we iterate to first, and all block meshes that use the same material. so, it's not *completely* unordered. but idk if one can call that front to back |
| 13:11 |
Desour |
anyway, it's likely this doesn't influence rendering performance much anyways |
| 13:13 |
sfan5 |
the per-material list is ordered front-to-back |
| 13:14 |
sfan5 |
I'm not sure about performance. rendering useless could be much worse on a low-end gpu with low fill rate |
| 13:14 |
sfan5 |
(since the depth test would just discard it if occluded) |
| 13:49 |
sfan5 |
also the way our code is written now we're assuming that material swaps are more costly than rendering fragments twice (or more) |
| 13:54 |
Desour |
it would be interesting to see if for some low end gpus number of fragments is actually more important indeed, and by how much |
| 13:57 |
sfan5 |
okay so https://github.com/minetest/minetest/commit/ee2d9d973a0397ce244f05d49083250956578780 introduced that |
| 13:57 |
sfan5 |
but it made in sense back in the day because the drawlist wasn't yet ordered |
| 13:58 |
sfan5 |
we have that since https://github.com/minetest/minetest/commit/f5040707fe7cf9f24274379598527d6298c5818c |
| 14:00 |
sfan5 |
anyway the optimization I proposed is free. we're just rendering solid buffers in a different order |
| 14:00 |
sfan5 |
the other thing depends heavily on the scene and probably the gpu (driver). |
| 14:03 |
sfan5 |
speaking of other things: does anyone want to create a backport branch? |
| 14:57 |
|
SFENCE joined #minetest-dev |
| 14:58 |
|
Desour joined #minetest-dev |
| 15:06 |
rubenwardy |
[10:57] <+sfan5> i need to stop before I surpass c55 |
| 15:06 |
rubenwardy |
Or maybe c55 needs to start again! |
| 15:17 |
|
SFENCE joined #minetest-dev |
| 15:18 |
Krock |
I missed the opportunity to blaze |
| 15:45 |
[MatrxMT] |
<Zughy> Reminder meeting today in a few hours |
| 16:00 |
MTDiscord |
<prolller> Dont forget discuss how to merge https://github.com/minetest/minetest/pull/11843 |
| 16:05 |
Desour |
!title |
| 16:05 |
ShadowBot |
Breaking world limits. Part 1 by proller · Pull Request #11843 · minetest/minetest · GitHub |
| 16:05 |
|
red-001 joined #minetest-dev |
| 16:32 |
sfan5 |
i wonder if we could use test scenes and software rendering to reasonably measure rendering performance and detect regressions |
| 16:32 |
sfan5 |
hell just having test scenes would be good |
| 16:34 |
Krock |
read-only maps exist but they'd be somewhat heavyweight for git |
| 16:41 |
|
v-rob joined #minetest-dev |
| 16:44 |
v-rob |
I'll be attending the meeting today, but will probably be a half hour late. |
| 17:26 |
|
Sokomine joined #minetest-dev |
| 17:31 |
Mantar |
Krock: that's what LFS is for |
| 17:39 |
Krock |
Mantar: if we'd want to add another dependency, then yes. |
| 17:39 |
Krock |
Meeting in 20 minutes |
| 17:51 |
sfan5 |
i will not be there |
| 17:57 |
Krock |
good to know. thanks. Pinging people who reacted. In advance. @sfence sfence v-rob (joins in 30 mins) Desour Zughy |
| 17:57 |
Desour |
o/ |
| 17:59 |
Krock |
might grorp / @grorp be available too? the more, the merrier. |
| 18:00 |
Krock |
Meeting start. https://dev.minetest.net/Meetings#2024-09-01 I'll be going through the milestone ( https://github.com/minetest/minetest/milestone/27 ) one by one |
| 18:01 |
Krock |
> #15000 |
| 18:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/15000 -- Major Server Performance Regression |
| 18:02 |
Krock |
there does not seem to be any definite explanation for this issue |
| 18:02 |
Krock |
perhaps it's touching multiple issues at the same time without any reasonable way to debug it |
| 18:04 |
Krock |
almost as if there's a new time catch-up mechanism that causes permanent lag |
| 18:05 |
Krock |
there's the glibc memory-free triggering function - which however should leave enough memory as a buffer |
| 18:09 |
Desour |
has there been anyone else than Warr1024 who was able to reproduce? |
| 18:11 |
Desour |
(oh, yes: https://github.com/minetest/minetest/issues/15000#issuecomment-2295272574 ) |
| 18:11 |
SFENCE |
This looks like we should develop some performance test for server-client or something like it. |
| 18:12 |
Krock |
I suppose it's difficult to catch memory usage spikes which could be a cause of such issue |
| 18:15 |
Krock |
Hopefully we'll get a lead on this. Until then I don't see a way to possibly fix it for 5.9.1. |
| 18:16 |
Krock |
If there's inputs from affected and unaffected server owners, please leave a comment. Maybe that could help to narrow down the issue. |
| 18:16 |
Krock |
> #14765 |
| 18:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/14765 -- New 5.9.0-dev networking is not allowing legitimate players to connect under some rare circumstances |
| 18:17 |
Krock |
s.f.a.n.5 is mostly on it. Same issue as above; difficult to reproduce. |
| 18:18 |
Desour |
#15087 |
| 18:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5 |
| 18:19 |
Desour |
^ he is on it |
| 18:19 |
Krock |
good. let's see what the testing yields |
| 18:20 |
Krock |
> #14999 |
| 18:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view |
| 18:22 |
Krock |
Same reproduce issue as already seen; also waiting for testing results. |
| 18:23 |
Krock |
more precisely - tests with software render and (partial) revert of 5280863 (which is apparently the first bad) |
| 18:24 |
Krock |
> #15005 |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/15005 -- Touchscreen can be enabled when device doesn't support touchscreen |
| 18:27 |
Krock |
solvable by additional settingtypes.txt "requires:" filters. not important from what I can see. |
| 18:28 |
Krock |
^ would need proper touch detection code that was previously discussed before the 5.9.0 release |
| 18:30 |
[MatrxMT] |
<grorp> that issue is not about physical device touchscreen support, but about Irrlicht device touchscreen support. win32 and osx Irrlicht devices don't support touchscreen input, so you could just hide the setting there. |
| 18:30 |
[MatrxMT] |
<grorp> but I agree with not important |
| 18:31 |
[MatrxMT] |
<grorp> well, actually it's bad UX if you have a Windows laptop with touchscreen, enable touch controls and it's just broken |
| 18:33 |
|
v-rob joined #minetest-dev |
| 18:33 |
Krock |
I see. Thanks for explaining. It should be rather simple to implement a per-device function to A) inform about touch support and B) the primary input device |
| 18:34 |
Krock |
where A) is used for settingtypes.txt and B) for the default |
| 18:35 |
v-rob |
I'm here now |
| 18:35 |
Krock |
hello v-rob. and also proper hello grorp. |
| 18:36 |
Krock |
B) ignores that there's #14542 that should fix the issue differently |
| 18:36 |
[MatrxMT] |
<grorp> "the primary input device" goes into #14933 terrain. detecting the last used input method is simpler and more useful. |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/14542 -- [no squash] Auto-toggle TouchScreenGUI in-game when receiving touch/mouse input by grorp |
| 18:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/14933 -- Implement an editor to customize the touchscreen controls by grorp |
| 18:36 |
[MatrxMT] |
<grorp> Krock: wrong PR number? |
| 18:36 |
[MatrxMT] |
<grorp> also, hello :) |
| 18:37 |
[MatrxMT] |
<grorp> ah, no, wait I linked the wrong one |
| 18:37 |
[MatrxMT] |
<Zughy> (I'm here as well, just reading) |
| 18:37 |
Krock |
you had me confused for a moment |
| 18:38 |
[MatrxMT] |
<grorp> I was confused by ShadowBot being late |
| 18:39 |
Krock |
however that PR is not labelled for 5.9.1 |
| 18:41 |
Krock |
so having a fix in 5.9.1 is currently not planned, unless that's at least linked in the issue |
| 18:41 |
[MatrxMT] |
<grorp> your B) or that PE isn't necessary for 5.9.1 |
| 18:41 |
[MatrxMT] |
<grorp> *PR |
| 18:44 |
Krock |
commented. |
| 18:44 |
Krock |
> #15056 |
| 18:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/15056 -- Android media timeout loading no longer allows me to join public servers |
| 18:45 |
Krock |
asked for more information. I've seen similar issues in the past. It seems to be recurring every now and then |
| 18:46 |
v-rob |
"Things are slower" issues always feel so nebulous |
| 18:46 |
Krock |
my toaster does not toast please fix |
| 18:46 |
Krock |
> #15087 awaits inputs from affected people https://github.com/minetest/minetest/issues/14765#issuecomment-2322913501 |
| 18:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5 |
| 18:47 |
Krock |
skipping #15095. it's a reminder. |
| 18:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/15095 -- Bump protocol version to 45 for 5.9.1 |
| 18:47 |
Krock |
> #15097 |
| 18:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/15097 -- touch_punch_gesture not only applied for actual punching |
| 18:48 |
Krock |
I'm out of the loop on that topic but reviews for #15098 are welcome |
| 18:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/15098 -- Only apply "touch_punch_gesture" when item has no on_use callback by grorp |
| 18:49 |
Krock |
mostly on the topic "whether it makes sense" and whether there's any new strange side-effect (hopefully not) |
| 18:50 |
Krock |
end of milestone. 5.9.1 is not realistic today. adding a few weeks. |
| 18:51 |
v-rob |
I definitely don't understand how short vs. long taps on touchscreens work |
| 18:51 |
[MatrxMT] |
<grorp> it's magic |
| 18:51 |
v-rob |
Goody, my favorite |
| 18:52 |
Krock |
at least it cannot be more cursed than inventory itemstack movements |
| 18:52 |
v-rob |
Those scare me |
| 18:52 |
v-rob |
And to think: I have write inventory code for the UI API at some point *shudder* |
| 18:53 |
Krock |
think of a PoC. it does not need to be feature-complete from day 0. it might be better to have the documentation separate so that modders do not take features for granted. |
| 18:53 |
[MatrxMT] |
<grorp> since there are already many fixed regressions, we could just do a 5.9.1 release with these fixes. if we manage to fix one of the yet-PR-less issues at a later point, we can still do a 5.9.2. thoughts? |
| 18:54 |
Krock |
for context: so far there's 9 merged PR's assigned to 5.9.1 |
| 18:55 |
Desour |
could add #14969 to make it 9 |
| 18:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/14969 -- Fix CMeshBuffer::append reallocating too eagerly by Desour |
| 18:55 |
Desour |
10* |
| 18:56 |
MTDiscord |
<luatic> do it |
| 18:56 |
Desour |
did it |
| 18:57 |
Desour |
we could also already make a branch for 9.1, so users can already test |
| 18:57 |
v-rob |
Minetest 9.1.0 |
| 18:57 |
Desour |
5.9.1* |
| 18:57 |
v-rob |
We're moving fast |
| 18:57 |
Krock |
they're already testing those in 5.10.0-dev, and rc builds are an option too, based on the 5.9.1 |
| 18:57 |
Krock |
PR that someone is going to open |
| 18:59 |
Krock |
I could open such PR until the next meeting if that's wanted. |
| 19:01 |
Krock |
normal meeting points. I did yet not set up a poll for the development cycle idea so that's a skip |
| 19:01 |
Krock |
> #11568 |
| 19:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/11568 -- Consider a separate repo for requesting and discussing new features |
| 19:01 |
|
v-rob joined #minetest-dev |
| 19:02 |
Krock |
Zughy: the matrix link is dead |
| 19:03 |
Krock |
I took the liberty to use the first post as a poll :3 |
| 19:05 |
MTDiscord |
<herowl> Fwiw, #14999 reminds me an issue we had once in VL with messed up animations. Bisect led me then to an unrelated commit. Commenting out lines led me to a mod.conf file. Issue was that mod load order got changed, which caused globalstep registration order to change, which caused globalstep execution order to change, which caused bone override order to change, which messed up some animations. |
| 19:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view |
| 19:06 |
MTDiscord |
<herowl> So maybe it's about some code execution order changing under some circumstances? |
| 19:06 |
Krock |
@herowl that's a nice input but unfortunately entirely unrelated in this case. it's rendering related, which cannot easily be changed by mods |
| 19:07 |
MTDiscord |
<herowl> Yeah, but rendering pipelines also have execution ordering by different things |
| 19:07 |
Krock |
if it's execution order related, then many more people should be active in that issue |
| 19:07 |
MTDiscord |
<herowl> You're overestimating the amount of people reporting such issues. It's a graphical glitch |
| 19:08 |
Krock |
retry with (partial) reverted 5280863. If reverting the entire thing does not solve it, then the earlier bisect is wrong. |
| 19:08 |
v-rob |
Zughy: What was in that matrix link? |
| 19:10 |
SFENCE |
In the case of moving features somewhere, I am afraid about users ability to follow that. Users can be confised by it. |
| 19:12 |
v-rob |
They might be somewhat confused, but we can easily redirect them: if you click "New Issue" in the Minetest repo, one of the options is a link to Minetest Game's repo. You could turn the feature request issue into a redirect to the features repo. |
| 19:14 |
[MatrxMT] |
<Zughy> sorry, internet hiccups |
| 19:14 |
[MatrxMT] |
<Zughy> v-rob, Krock: people debating about having two separate repos |
| 19:14 |
SFENCE |
It will require some issue auto moving... sometimes someone report bug, and it is labeled as feature request and etc. |
| 19:15 |
v-rob |
Is it easy to move issues between repos in GitHub? |
| 19:15 |
v-rob |
We have to tag new issues/feature requests anyway |
| 19:15 |
Krock |
yes but you need to have member access to both |
| 19:15 |
Krock |
MTG issues are moved there from the engine on a regular basis |
| 19:17 |
[MatrxMT] |
<Zughy> https://matrix.org/_matrix/media/v1/download/matrix.org/UksrVxBQieecMsnyPAxmWoXH |
| 19:17 |
v-rob |
That link works |
| 19:19 |
Krock |
"too many open issues bury the actual problems" - this is not quite true, assuming that people can find their issue and leave a "me too, reproduced on X, Y and Z with A B and C" to bring the issue forwards. That's also why there's priority labels and milestones. |
| 19:19 |
SFENCE |
So, we will have ability to ignore feature repo issues. Will it help users? |
| 19:20 |
v-rob |
Can issues be added to milestones in another repo? |
| 19:21 |
[MatrxMT] |
<Zughy> https://matrix.org/_matrix/media/v1/download/matrix.org/QKznVFyhVzTPPILFzJafUOBY |
| 19:21 |
[MatrxMT] |
<Zughy> https://matrix.org/_matrix/media/v1/download/matrix.org/qmJrdJUbPuczznvAcvjBPmxn |
| 19:21 |
Krock |
v-rob: milestones are on a per-project basis and I don't see any option to include such from other sources |
| 19:21 |
[MatrxMT] |
<Zughy> the end |
| 19:23 |
Krock |
SFENCE: what helps the users is if they can find an issue they discovered quickly. |
| 19:23 |
v-rob |
Milestones are rather important for project management. If we have a separate repo, we need to have a replacement. |
| 19:23 |
MTDiscord |
<herowl> I don't think separating it is a good idea. |
| 19:23 |
|
nekobit joined #minetest-dev |
| 19:24 |
Krock |
separating feature requests and issues can help in this regard but only to a limited degree |
| 19:24 |
v-rob |
It would be nice if GitHub had separate "Issues" and "Requests" sections in the same repo. |
| 19:25 |
v-rob |
Or if there were a more hierarchical way to organize issues |
| 19:25 |
v-rob |
Labels are a rather "flat" means of organization |
| 19:26 |
SFENCE |
I do not think that it will help to find some issue much quicker with separate repo. There is many of feature request still. It will be still best to use filtering by name, I expect. Now you should filret by name and label. |
| 19:26 |
Krock |
combining related issues is kind of possible with the "Projects" page |
| 19:27 |
v-rob |
The problem with projects is that issues can get "lost" if they aren't added |
| 19:27 |
Krock |
it's not a hierarchy, though. and dividing it into such is extremely difficult because issues can touch more than one code area, depending on how you interpret the issue or solution |
| 19:28 |
MTDiscord |
<herowl> Projects should be used for what their name implies IMHO. |
| 19:28 |
[MatrxMT] |
<Zughy> v-rob: make a PR to GitHub to implement th.. Oh, wait, it's proprietary, you can't |
| 19:28 |
v-rob |
Some things are hierarchical, like bug vs. feature vs. meta discussion, also high vs. med vs. low priority. Things like the @ labels are definitely better as labels, not hierarchy though |
| 19:28 |
MTDiscord |
<herowl> Minetest move to Codeberg when? |
| 19:29 |
v-rob |
Bascially, I'd love it if mutually exclusive labels could have their own sections. |
| 19:29 |
v-rob |
But this is all wishful thinking. I don't know of any git platform with such a means of organization |
| 19:30 |
v-rob |
Anyhow, it seems that quite a few people disagree with separating issues and features. |
| 19:31 |
Krock |
Zughy: if you'd like to have a definitive answer, please set up a poll in the issue or forums |
| 19:31 |
v-rob |
Agreed |
| 19:31 |
Krock |
> Thoughts on the latest proposed core dev |
| 19:31 |
Krock |
wasn't this already discussed? |
| 19:33 |
Krock |
In either case - the meeting is already going on for 1.5 hours and I think that's a good summary for 5.9.1 |
| 19:33 |
Krock |
I'll include a few meeting notes in the wiki and close it at this point. If you have any other topics, please bring them up. |
| 19:34 |
v-rob |
I had a few things I wanted to talk about for #14263. |
| 19:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/14263 -- Formspec/HUD replacement, part 1 by v-rob |
| 19:34 |
v-rob |
It's currently milestoned for 5.11.0, which seems reasonable enough. |
| 19:35 |
v-rob |
In the meantime, what should be done about formspec PRs? I don't want to stop them altogether, but it would be nice if we could slow down adding features |
| 19:36 |
v-rob |
For instance, #14728 is a large new feature |
| 19:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/14728 -- [NO SQUASH] Add hypertext support to tooltips by Wuzzy2 |
| 19:37 |
v-rob |
Whereas #14840 is an important quality-of-life thing for formspecs |
| 19:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/14840 -- Improve formspec scaling by grorp |
| 19:38 |
v-rob |
The UI API is obviously not going to be finished for a while yet, so the latter is important, but I think we should avoid merging ones like the former. If we get a new API soon, then extra formspec features just means more work when making formspec compatibility code. |
| 19:40 |
Krock |
I think we should begin to discourage entirely new formspec features as soon the replacement is on a condition where we are sure to build onto |
| 19:40 |
v-rob |
(Although, since hypertext is technically experimental, it could be nuked entirely, though that would make quite a few people unhappy) |
| 19:40 |
v-rob |
What point do you think that would be? |
| 19:44 |
Krock |
I'd say when the basic formspec replacement (it does need a fancy name, maybe formspec2 :P ) is in master for at least a release for modders to check it out and provide suggestions. |
| 19:45 |
Krock |
You surely spent many hours on the concept and implementation, and yet, the best testing is done by modders who try to find its limits |
| 19:45 |
v-rob |
That's definitely true |
| 19:45 |
Krock |
and such limits are likely discovered by wrapper mods that provide formspec + formspec2 support |
| 19:45 |
v-rob |
I've been calling it the UI API in the official docs |
| 19:46 |
Krock |
(to convert into both, for client compatibility) |
| 19:46 |
Krock |
of course, for the transition phase it would be amazing if formspecs could be included as a separate element in the UI API |
| 19:46 |
Krock |
but that might as well come with an entire can of worms |
| 19:47 |
v-rob |
If you have a formspec -> UI element converter function, it should be more or less doable. |
| 19:48 |
v-rob |
How far do you think basic support would be for modders to get a good feel for the UI API? Obviously things like buttons and scrollbars and edit boxes, but what about more complicated things like inventory lists, tooltips, and tables? |
| 19:49 |
v-rob |
Sizer support is also a definite must. |
| 19:50 |
v-rob |
(I keep trying to keep sizers as simple as possible, but I keep finding that there's some features that are indespensible for good layout, so I have to do some reworking again. Most annoying.) |
| 19:50 |
Krock |
depends on how you'd first want to use them. The UI API is supposed to replace formspecs, thus it should work on node-bound basis and in their "detached" form. Nodes generally need inventory lists, but for a PoC that's IMO not needed. |
| 19:51 |
v-rob |
Aside from finishing up sizers, text is the only other large feature that I have quite a bit of work for |
| 19:51 |
Krock |
(where "should work on" can also be answered by the design of the API, i.e. how the data is saved to the metadata) |
| 19:52 |
rubenwardy |
I don't think it's necessary to have table support if you have primatives like flow, grid, and clickables |
| 19:52 |
v-rob |
I personally want to deprecate node metadata formspecs entirely, though they'll stick around for compatability. You can't put the UI API into node metadata because it isn't string based. The UI API makes things really easy in an `on_rightclick` handler, so I don't see the need. |
| 19:53 |
Krock |
aligning, aspect ratio, and callbacks are probably the most important |
| 19:53 |
v-rob |
Callbacks are fully implemented, and very nice to use compared to formspec events |
| 19:54 |
rubenwardy |
s/flow/flex |
| 19:54 |
v-rob |
Callbacks are placed directly in the element: `ui.Checkbox{id = "check", on_change = function(e) if e.selected then print("Checked") else print("Unchecked") end end}` |
| 19:57 |
v-rob |
I can give a basic timeline: 1) Current PR (windows, buttons, events, styling) is basically done, I just need to address any review comments that come up and make a test suite |
| 19:57 |
|
SFENCE joined #minetest-dev |
| 19:58 |
v-rob |
2) PR with scrollbars, scroll containers, and other simple elements that don't require text would take a few weeks |
| 19:59 |
v-rob |
3) Sizers are 90% done, but the last 10% takes 90% of the time, as they say :) Still, a few weeks is a good estimate. If modders find problems with sizers, I can always make more PRs that incorporate their feedback. |
| 20:01 |
Desour |
tbh, I kinda like that in formspecs you don't define the callback inside the form definition. the separation feels somewhat clean |
| 20:01 |
v-rob |
4) Text will take a few months. This includes incorporating a text layout library, making a serialization format to handle rich text like bold and italics, hopefully bidi support at the UI level, and so on. A PoC doesn't need every feature, however. |
| 20:02 |
v-rob |
After that, I think the UI API is ready enough for modders to use and give feedback on |
| 20:02 |
v-rob |
Even without text, there's a lot to give feedback one |
| 20:02 |
v-rob |
*on |
| 20:03 |
[MatrxMT] |
<Zughy> Re 5.9.1: I don't think we should delay it even more, +1 for a hypothetical 5.9.2 to release 5.9.1 soon |
| 20:03 |
[MatrxMT] |
<Zughy> I really don't want to rush the name change for the reasons listed in the internal discussion, nor to postpone it for the same reason |
| 20:04 |
[MatrxMT] |
<Zughy> And it's not like it gonna takes a couple of days to rename everything |
| 20:04 |
Krock |
I'll have to check out the UI API PR in a while. Your most recent summary is a great overview. |
| 20:05 |
v-rob |
Desour: I didn't opt for a single separate callback for a few reasons. One good reason is that it allows modders to add and remove callbacks at will when they update the window. Another is that it reduces network traffic: the client only sends the events that the server is listening for. |
| 20:06 |
v-rob |
Krock: I'll be pushing my changes for grorp's review in a few days. Give it another week or two and I'll have a test suite ready out-of-the-box in devtest and documentation included in the PR as well. |
| 20:08 |
SFENCE |
If 5.9.1 comes quickly, I want to add one trivila PR to it to improve MacOS support to MacOS 12 and later. |
| 20:08 |
[MatrxMT] |
<Zughy> v-rob: also take in consideration a PR to edit the roadmap, so to state that big formspec PRs are a no no |
| 20:08 |
Krock |
v-rob: wow that's great news. |
| 20:09 |
SFENCE |
We should mention it somewhere that we dont want other features for formspec to be done for now. |
| 20:09 |
v-rob |
The documentation already exists, but it includes some features that aren't in the current PR yet :) |
| 20:09 |
v-rob |
So I need to prune it a bit |
| 20:10 |
[MatrxMT] |
<Zughy> If the roadmap is modified, I can manually go through every issue/PR to close them (with a message ofc) |
| 20:10 |
[MatrxMT] |
<Zughy> There's already a list by v-rob I can use |
| 20:10 |
v-rob |
https://github.com/minetest/minetest/pull/14263#issuecomment-2322659272 |
| 20:10 |
v-rob |
How convenient :) |
| 20:10 |
Krock |
gtg |
| 20:11 |
v-rob |
Bye then |
| 20:11 |
v-rob |
Guess I'll get back to work myself. Those reviews aren't fixing themselves. |
| 20:12 |
celeron55 |
i have a late thing for the agenda of the meeting, now that many people are still around |
| 20:13 |
celeron55 |
ok that's two gone already |
| 20:13 |
celeron55 |
well anyway... |
| 20:14 |
celeron55 |
i talked with y5nw about adding them to the core team. y5nw would be starting slowly as they don't know that much of the codebase but would be ready to join. so, i'm asking for comments from the core team |
| 20:16 |
celeron55 |
y5nw is also fine with joining later. so alternatively we can e.g. schedule it, or whatever. but that feels awfully arbitrary to me, so i'm proposing just adding to the team |
| 20:17 |
[MatrxMT] |
<Zughy> Can't judge their coding skills but I've met them at FOSDEM and they're cool |
| 20:18 |
celeron55 |
(looks like i'm way too late here, maybe i'll ask again tomorrow. the reason for the timing is, i just managed to get to my computer...) |
| 20:18 |
|
v-rob joined #minetest-dev |
| 20:33 |
|
Sokomine joined #minetest-dev |
| 20:43 |
|
SFENCE joined #minetest-dev |
| 20:50 |
|
v-rob joined #minetest-dev |
| 21:01 |
|
SFENCE joined #minetest-dev |
| 21:35 |
|
SFENCE joined #minetest-dev |
| 21:57 |
|
SFENCE joined #minetest-dev |
| 22:28 |
|
SFENCE joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:47 |
|
SFENCE joined #minetest-dev |
| 23:04 |
|
SFENCE joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:30 |
|
SFENCE joined #minetest-dev |
| 23:43 |
|
v-rob joined #minetest-dev |
| 23:49 |
|
SFENCE joined #minetest-dev |
