Hi there,

I have co-written a mod named AbandonedRuins_updated_fork: https://mods.factorio.com/mod/AbandonedRuins_updated_fork Where I have (not committed/uploaded yet) a storage table storage.allowed_planets[name] = allowed where name is the name from LuaPlanet class and allowed is a boolean value. Since I cannot add "dynamic" settings with data:extend() during the runtime stage, I have write an own GUI where players can allow/disallow ruins to be spawned on all available planets. There is a mod named AbandonedRuins-PlanetSettings but as you can see in its control.lua and settings.lua they have a static list of planets which isn't exactly how it should be done.

So I came up with iterating over game.planets to find all registered planets. I already have written the logic part (no spawning when planet is disallowed) but the GUI part is missing.

So I wonder if you can provide some tutorials? I find the current example relatively hard to understand. And can you provide some "generic GUI elements" which can I simply use and invoke?

I imagine something like this:

-- Header:
local glib = require("__glib__/glib")

-- Somewhere in my code:
local gui = glib.create_default_gui("ruins-spawning-on-planets", features = {"apply-button", "cancel-button", "localized-2col-list"}) -- the string is taken as name and localization key, too.

-- Add localized headers so the player knows what is for what
gui.set_header_row({"ruins-planet", "ruins-allowed-spawning"})

-- Simply handle over the whole table
gui.add_boolean_rows(storage.allowed_planets, callback=planets.handle_allow_callback)

-- Show the GUI
gui.show()

So when the user clicks on "Apply" button, a temporary table with same name as key and allowed(true|false) is generated (by your code) and handled over to the callback function planets.handle_allow_callback where my code can handle the update of storage.allowed_planets. The "Cancel" button dismisses all changes, no callback is done.

My idea was that mod developers don't have to write all over again but can use simple functions to create their GUIs.

Remarks:

• create_default_gui should always create a default frame with (internal?) name and localized title plus a X in upper-right corner with default close ("Cancel", nothing changed). The ESC key should trigger "Cancel/close", too.
• add a gui.replace_close_handler(my_lib.my_close_event_handler) if the developers wants to have their own event handler
• the said custom close-event handler should take gui as a parameter, it then needs to handle closing/destroying the GUI by itself.
• The parameter callback is mandatory as there is no generic way of applying changes, unless you know how?
• gui.set_header_row() should validate if the amount of header columns are matching the type of the desired item list (see below)

Possible item lists:

• simple-2col-list - A simple 2-column list for key/value tables, The table should be a simple key/value table, e.g. foo["bar-enabled"] = true or foo["bar"] = "baz", means having scalar/simple variable types as values, key is taken as 1st column's value, value for 2nd column's value, no localization done for both columns
• localized-2col-list - Same as above simple-2col-list but 1st column's value is now taken as a part of a localization string, optional parameter prefix="foo-bar-" is taken as a prefix for all localization strings
• multi-col-list - A multi-column table, optional parameter columns=x must be set to define how many columns are being expected, the table then should be iterated with for _, row in pairs(rows) as the key is ignored

Types <simple|localized>-2col-list can handle:

• boolean results in 2nd column as a checkbox as Factorio does in mod-settings
• number/string results in a text input-box
• "array/list" like `foo = {"bar", "baz"} results in a selection box

I guess this is all for simple 2-column lists. Other complex data structures can still be supported by the usual "manual" way. :-)