Time  Nick        Message
20:26 v-rob       Formspec refactoring progress so far: https://github.com/minetest/minetest/issues/9358#issuecomment-681103631
20:31 sfan5       great
21:07 DS-minetest v-rob: nice! but: wouldn't it make more sense to use a different ParserState in the creation of the gui objects and the parsing of the formspec element strings
21:09 DS-minetest eg. parse_button does not need to know about a current_parent (which is a gui::IGUIElement and doesn't have to do anything with the formspec string parsing)
21:10 DS-minetest (oh, and I'd suggest to return a unique_ptr in FormSpecParser::parseElement)
21:13 v-rob       ParserState is very much a work in progress
21:13 v-rob       ATM, GUIFormSpecMenu has it too, but later, FormSpecParser alone will have it
21:13 v-rob       So things like current_parent will be moved out
21:14 DS-minetest ah, I see
21:14 v-rob       Yeah, probably should use smart pointers
21:17 rubenwardy  I'm not fond of the separation between parsing and element creation, most of the effort is in the latter and there's still a lot in GUIFormspecMenu
21:18 rubenwardy  Hugues' idea to start with seperating GUIElements from GUIFormspecMenu is probably a better starting place
21:19 DS-minetest what IS GUIFormspecMenu anyway? or what should it be?
21:19 v-rob       The root element
21:20 v-rob       I'm doing parsing first because I have a good idea of what I want to do there
21:20 v-rob       Removing GUIElements is also high priority, but that will take more time for me to figure out
21:21 v-rob       Parsing's pretty easy to remove, but there's a lot of it littered everywhere
21:22 DS-minetest the root element is actually a StaticText: https://github.com/minetest/minetest/blob/e5725dfb8e476a5a6f63f020a23a53ca3ef610e9/src/client/clientlauncher.cpp#L236
21:22 v-rob       Well, the root for formspecs
21:24 DS-minetest imho an element (even if it's the root for something) shouldn't create its own elements. otherwise its functions that are called while it is "alive" as gui element are mixed up with its function that are used for gui creation
21:25 v-rob       Definitely, but that's a later refactor
21:26 v-rob       I just don't think relegating it to parsing is any better
21:26 v-rob       I think there should be a third party
21:26 Lone_Wolf   Would be nice if Discord users that are voiced here could also talk here. But to get to what I came here to say: What are all of these 'At the middle of the screen' comments on the infotext code?
21:26 Lone_Wolf   It's clearly not set to the middle of the screen
21:30 DS-minetest Lone_Wolf: isn't this eg. text on signs?
21:30 Lone_Wolf   That and object info
21:30 DS-minetest it is in the middle of the screen
21:30 DS-minetest in the vertical middle
21:30 Lone_Wolf   It collides with the chat for me
21:30 DS-minetest horizontally it's left
21:31 Lone_Wolf   It is in the top left for me
21:31 DS-minetest can you show a screenshot?
21:32 v-rob       Top left for me too. Seems to be a hardcoded distance from the top left from what I can see
21:33 Lone_Wolf   https://cdn.discordapp.com/attachments/453772264542961666/748293921809104927/unknown.png
21:33 Lone_Wolf   I may have set my hud scaling to a non-default value
21:33 Lone_Wolf   Nope
21:34 Lone_Wolf   Well my PR should fix this
21:36 DS-minetest hm, it is also in the upper-middle left for me now too (I somehow remembered this wrongly)
21:38 Lone_Wolf   I could swear it was different in 0.4.x
21:38 Lone_Wolf   Does moving it to center right above the cursor sound good?
22:11 appguru     Never had infotext at the middle of the screen.
22:12 appguru     Moving and hoping it does not collide is another unclean solution
22:12 DS-minetest it probably depends on screen size
22:12 appguru     What we would actually need would be layouting for the HUD
22:13 appguru     For now, infotext could just be sufficiently moved downwards if it collides with the chat
22:13 appguru     That should be pretty trivial to do