| Time |
Nick |
Message |
| 01:02 |
|
v-rob joined #minetest-dev |
| 02:37 |
|
v-rob joined #minetest-dev |
| 03:29 |
|
Alias joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:47 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:00 |
|
calcul0n joined #minetest-dev |
| 06:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:20 |
|
fluxionary joined #minetest-dev |
| 11:47 |
|
appguru joined #minetest-dev |
| 13:11 |
|
turtleman joined #minetest-dev |
| 13:23 |
|
imi joined #minetest-dev |
| 14:05 |
|
vampirefrog joined #minetest-dev |
| 14:51 |
|
Wuzzy joined #minetest-dev |
| 14:51 |
Wuzzy |
will the release dedication (TurkeyMcMac) be removd for 5.8.0? |
| 14:52 |
[MTMatrix] |
<Zughy> Yes |
| 17:28 |
|
fluxionary joined #minetest-dev |
| 19:23 |
|
v-rob joined #minetest-dev |
| 19:33 |
v-rob |
Got a question of opinion about the Lua API for the formspec replacement that I'm on the fence about. For formspecs, any time you want to change anything, you generally rebuild the entire GUI string and send it across the network. Internally, the new GUI does the same thing (but in a smarter way than formspecs with better state management). In contrast, many common GUI systems prefer to keep the existing GUI tree around, and to change it, you mutate |
| 19:33 |
v-rob |
the tree by adding attributes and adding and removing elements. |
| 19:34 |
v-rob |
I strongly prefer a "rebuild everything" approach (not using formspec strings, of course!) because immutability is very nice here and circumvents the annoying bookkeeping of having to synchronize your internal state and GUI tree--just rebuild every time. It also simplifies the Lua API implementation. However, I don't know if that's the way other people feel about it, so I don't want to lock us into an API that fundamentally doesn't allow GUI trees to |
| 19:34 |
v-rob |
be manipulated after creation. |
| 19:34 |
v-rob |
Furthermore, even if I did go with a rebuild everything model, is it desireable to be able to traverse the GUI tree and examine it, or should the tree be entirely opaque to the user such that they can create it and then be unable to do anything else with it besides sending it across the network? |
| 19:34 |
v-rob |
I want to decide on this one way or the other so I can finalize this darn API and get back to backend implementation... |
| 19:38 |
Krock |
v-rob: whether you send it incrementally or entirely does not really matter as long you can keep the input values persistent across formspecs. for that you have to have a tracking number (internally, hidden from API) to properly preserve the state |
| 19:39 |
Krock |
it would of course be handy to mutate a "formspec userdata instance" to add elements and read out values or register callbacks, but I suppose that's already been suggested in the formspec replacement issue |
| 19:39 |
v-rob |
It already does that internally: each element has a unique ID string for state tracking. I send the entire GUI across the network every time internally. This is entirely a question of external API design. |
| 19:40 |
v-rob |
As in, should elements have methods like `add_child()` and `set_id()` for mutation after creation, or should you just rebuild the GUI from scratch every time? |
| 19:41 |
v-rob |
The latter is the way that https://github.com/luk3yx/minetest-flow does it (if I'm not mistaken--I |
| 19:41 |
v-rob |
've never actually used it) |
| 19:41 |
v-rob |
The former is the way that traditional GUI frameworks do it. I've always found it clunky and annoying. |
| 19:46 |
luk3yx |
I prefer the rebuilding every time approach (though I'm probably a little biased), though it may be nice to have separate "widgets" that can be rebuilt without calling the entire build function again (as a solution for https://github.com/minetest/minetest/issues/9364). |
| 19:47 |
Krock |
MyFormspec:child("my_button):remove() wouldn't be an option then? You could create a new instance or mutate the current one if it happens to be an object |
| 19:48 |
Krock |
whatever the modder prefers to do. at the end it would just "compile" the object into something that can be sent over the network |
| 19:49 |
Krock |
please interrupt me in case I'm somewhat out of the loop for some reason |
| 19:51 |
Mantar |
Rebuild sounds fine to me |
| 19:52 |
v-rob |
The question is, how many modders would prefer to do :child("my_button"):remove() if it existed, rather than rebuilding? |
| 19:52 |
Mantar |
Yeah, I don't see that being particularly useful to me |
| 19:52 |
v-rob |
If modders want it, I'll add it, but I don't want to spend the time if people would just prefer to rebuild. |
| 19:52 |
Mantar |
Count me as one for just rebuild it |
| 19:53 |
Krock |
it's a question of concept. I don't think it makes a difference whether you create a whole new instance every time or recycle the existing one |
| 19:53 |
Krock |
modders will use whatever the API offers |
| 19:53 |
Mantar |
Way I see it, I have to write code to build it, so I can just call that again, then I don't have to worry about state |
| 19:54 |
Krock |
or rather what they prefer. If you really would like to know, you could propose a code example and open a poll on the forums |
| 19:55 |
v-rob |
Yeah, I'll probably end up doing that. |
| 20:41 |
|
appguru joined #minetest-dev |
| 20:41 |
v-rob |
https://forum.minetest.net/viewtopic.php?p=430742 |
| 21:27 |
|
mtvisitor joined #minetest-dev |
| 22:32 |
|
v-rob joined #minetest-dev |
| 22:41 |
|
appguru joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
