GUIs refactor using mod-gui

[RedRafe]

Description

Base game offers core/mod-gui.lua as a collective system to register buttons and frames in gui.top and gui.left. I think it looks cleaner overall so I took the chance to renovate the whole look (note: for the theme, we could also switch to light mode and have light-grey buttons over the darker background, but I think this looks more up-to-date...)

Migration

mod-gui adds a few more nested GuiElements, so

I. gui.left -> gui.left.mod_gui_frame_flow
II. gui.top -> gui.top.mod_gui_top_frame.mod_gui_inner_frame

overall, the lib itself takes care of ensuring that those children are always present when adding to them, so our utils/gui.lua lib simply relies on it and replaces all instances of player.gui.top[element_name] with Gui.get_top_element(element_name) (same for left, both with get and add methods).

To get the "new actual" gui.top element, Gui.get_top_flow(player) is used instead (same for left).
The new system requires the top-level-child to have a name when adding to mod-gui, so I've added UIDs to those few flows that didnt have it

Changes

• new left flow is now horizontally instead of vertical
• changed utils/gui.lua lib and added default styles for all top/left elements
• changed all top buttons (and score frame) to new system
• top buttons do not change button style to "highlighted" version when toggled
• changed all left frames t new system
• changed gui.test, in particular

local function count_gui_elements(player)
    -- local gui = player.gui
    -- return #gui.top.children + #gui.left.children + #gui.center.children
     return #Gui.get_top_flow(player).children + #Gui.get_left_flow(player).children + #player.gui.center.children
end

I hope this maintains the same logic as before? Counting the actual added children? Also gui.screen was not present and I did not add, don't know if that was on purpose

• Fixed Tetris map with invalid utility/clear sprite
• Changed cutscene buttons
• Removed top gui restyle from player_create.lua and moved to gui.lua instead at same event ID

Test

• I've tested all the common top Gui buttons and their linked left-frame actions
• Tested Quadrant map
• Tested Tetris map
• Tested Crash Site map
• Tested Danger Ores map
• Tested Diggy map

Here's a preview of the changes: I plan to come back and maybe refactor some of the left frames as well to make them more "factorio-like" in the future instead of plain grey windows.

[grilledham]

Just a heads up that I probably won't be able to review this before the weekend. In the meantime it might be worth posting a before and after screenshot in the admin channel just to make sure people know what is coming.

[grilledham]

I pushed a change to fix the gui tests, hope that is ok. You can run the tests with the /test-runner command.

[grilledham]

The paint brush button has a smaller sprite now.
Before:

After:

Not major, but I wonder if we can do something about that.

[grilledham]

When the top buttons are collapsed, the show/hide button no longer reduces in vertical space. Is that a deliberate change? I can live with it, maybe it's better when you have modded buttons as well, but I preferred the smaller button.

Before:

After:

[grilledham]

top buttons do not change button style to "highlighted" version when toggled

I don't like this change. Is this a temporary change, or is difficult to get this working?

[grilledham]

Code looks fine to me. I tested it and didn't find any problems (apart form with snake, which no one uses anyway).

There are a few minor style changes that I think we should change, or for you to say you don't think we should change.

[RedRafe]

I will advance that all choices were made by design and are purely subjective choices, I don't have too strong feelings about keeping or changing any of these :)

The paint brush button has a smaller sprite now.

That's because I added some padding to it b.style.padding = 2 because I thought it looked more natural (BW .png are usually padded +2 in vanilla, while other colored sprite look better even with negative padding -2 to make them look bigger), but I can decrease it to 1/0/-1 to make it bigger

When the top buttons are collapsed, the show/hide button no longer reduces in vertical space. Is that a deliberate change?

Yes, it was deliberate that the hide/shows button stays consistent in size as other mods buttons will not be hidden (only Redmew's) and they all share the same "cage". But I could make it shrink again if we want, it just wont matter much if other buttons are there as well

[top buttons not toggling the highlight] I don't like this change. Is this a temporary change, or is difficult to get this working?

Was just a design choice. Some buttons had the highlight toggle, some didn't which was a bit inconsistent. Most of the buttons open a left window that have a "close" button on their own, so it would need to react & change the button state in multiple places for little benefit(?). Ideally, I think it would be cleaner to use the flag auto_toggle = true when creating the top button element, and just toggle it again when closing one of those left windows from their custom close button, instead of setting it true/false reacting on all GUI events related to it

[RedRafe]

Also I'm noticing your before/after Paint icon looks a lot more smaller than the ones on my screen

This is still with padding = 2 and looks completely different from your screenshot

[grilledham]

Also I'm noticing your before/after Paint icon looks a lot more smaller than the ones on my screen

Maybe this is because of interface UI scale settings, I use 175%, but if I switch to 100% it looks like yours.

When the top buttons are collapsed, the show/hide button no longer reduces in vertical space. Is that a deliberate change?

Yes, it was deliberate that the hide/shows button stays consistent in size as other mods buttons will not be hidden (only Redmew's) and they all share the same "cage". But I could make it shrink again if we want, it just wont matter much if other buttons are there as well

Fair enough, I wondered if it was to do with mod buttons. I think we can keep this change then.

[top buttons not toggling the highlight] I don't like this change. Is this a temporary change, or is difficult to get this working?

Was just a design choice. Some buttons had the highlight toggle, some didn't which was a bit inconsistent. Most of the buttons open a left window that have a "close" button on their own, so it would need to react & change the button state in multiple places for little benefit(?). Ideally, I think it would be cleaner to use the flag auto_toggle = true when creating the top button element, and just toggle it again when closing one of those left windows from their custom close button, instead of setting it true/false reacting on all GUI events related to it

All of the Redmew buttons that open a window had the highlighting working before, so I'm not sure what you mean by the inconsistency. I can live without the highlighting, but it was deliberate choice to put it in.

[RedRafe]

I will add the toggle back its not a biggie, it was a feature we had, happy to maintain it if players find it useful

Good catch on the UI scale! I would never have guessed. I looked at the API and didn't find anything to make it scale better with interface % (it does look a bit weird that it's not consistent to button size when changing zoom from 75% to 200% tho)

[RedRafe]

There is LuaPlayer::display_scale that I guess would probably tell the UI zoom, question is do we want to support this with the icon size?

[grilledham]

There is LuaPlayer::display_scale that I guess would probably tell the UI zoom, question is do we want to support this with the icon size?

That is possibly getting a bit too complicated. The styling issue is minor, so I'd be happy to leave it.

[RedRafe]

@grilledham there's a couple more issues on which I'd like to hear your feedback, when using mods:

1. the size of buttons is 36 (which with 2 border of cage on top/bottom makes it 40 in size), but mods are likely to add 40x size inside the mod gui resulting in those 4 extra gap on the bottom. Should:
   A. keep it default 36 +2+2 and not care
   B. make it default 40 +2+2 all the time
   C. keep default 36 +2+2 and change other buttons to be 36x as well
   D. keep default 36 +2+2 but make it 40 +2+2 if other mods/mods gui are present

2. The fully opened score GUI may open on the last spot of the top panel. Should this:
   A. remain as is, scoreboard as rightmost element
   B. always add on the close right of the score gui button, before other mods

[grilledham]

1. If mods typically add buttons at size 40, I think we should make our buttons the same size. Of course, we can never guarantee the size of mod buttons and they could dynamically change them after created. So it'll never be perfect but I think that is the best we can do.

2. I think it'd be better if it opened to the direct right of the the score button, but it's not major, so happy to leave it.

[grilledham]

LGTM. Thanks for updating our gui to use a more modern style.