| Time |
Nick |
Message |
| 00:59 |
|
olliy joined #minetest-dev |
| 01:44 |
|
Seirdy joined #minetest-dev |
| 02:11 |
|
absurb joined #minetest-dev |
| 06:51 |
|
absurb joined #minetest-dev |
| 07:49 |
|
search_social joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:47 |
|
calcul0n joined #minetest-dev |
| 09:19 |
|
Darcidride joined #minetest-dev |
| 09:37 |
|
BuckarooBanzai joined #minetest-dev |
| 10:00 |
|
Darcidride joined #minetest-dev |
| 10:12 |
|
proller joined #minetest-dev |
| 10:49 |
|
Taoki[laptop] joined #minetest-dev |
| 10:50 |
|
Fixer joined #minetest-dev |
| 12:03 |
|
Darcidride joined #minetest-dev |
| 12:53 |
|
Fixer_ joined #minetest-dev |
| 12:58 |
|
Krock joined #minetest-dev |
| 14:51 |
|
Fixer joined #minetest-dev |
| 15:16 |
|
twoelk joined #minetest-dev |
| 15:43 |
|
appguru joined #minetest-dev |
| 16:38 |
|
fluxflux joined #minetest-dev |
| 17:08 |
|
olliy joined #minetest-dev |
| 17:24 |
|
olliy joined #minetest-dev |
| 17:53 |
|
GreenXenith joined #minetest-dev |
| 17:59 |
|
MTDiscord joined #minetest-dev |
| 18:03 |
|
appguru joined #minetest-dev |
| 18:22 |
|
DS-minetest joined #minetest-dev |
| 19:10 |
|
proller joined #minetest-dev |
| 19:13 |
|
v-rob joined #minetest-dev |
| 19:18 |
|
YuGiOhJCJ joined #minetest-dev |
| 19:30 |
|
Lone_Wolf joined #minetest-dev |
| 19:50 |
|
pyrollo joined #minetest-dev |
| 20:12 |
|
proller joined #minetest-dev |
| 20:14 |
|
appguru joined #minetest-dev |
| 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:24 |
|
Lone_Wolf joined #minetest-dev |
| 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 |
| 22:16 |
|
Shara_ joined #minetest-dev |
| 22:27 |
|
tyler-2 left #minetest-dev |
| 23:01 |
|
tyler-2 joined #minetest-dev |
| 23:09 |
|
fluxflux joined #minetest-dev |
| 23:16 |
|
twoelk left #minetest-dev |
| 23:23 |
|
tyler-2 left #minetest-dev |
| 23:23 |
|
tyler-2 joined #minetest-dev |
