Open Athozus opened 7 months ago
are those functions/features already used elsewhere?
No, they are not. But GUI helpers could be used for every Minetest mod using formspec, and settings for example with i3 which is using settings.
And anyway, it's like the wrench which has its own mod now, because it was unrelated to technic. This one, we have a lot of helpers that are not directly related to mail, so why not share them ?
This one, we have a lot of helpers that are not directly related to mail, so why not share them ?
Mostly commenting and adding reasoning for "why not?" part:
Can you prove, through actual use cases and API stability stats, that those are actually good enough for real generic use?
Many library projects fail because of trying to provide useful and generic stuff without really field testing it first, and when you fail once people will remember not to waste time with it again. Doesn't matter if you fix the issues.
It only really makes sense to create a library mod when code is already being copy-pasted between mods, vizlib
and xcompat
are good examples of this. In this case, I think it's a bad idea.
And anyway, it's like the wrench which has its own mod now, because it was unrelated to technic.
That's a bad comparison. The wrench
mod was separated to make it easier to maintain, and because it could be used without technic
, it made sense to make it available separate from the modpack.
Can you prove, through actual use cases and API stability stats, that those are actually good enough for real generic use?
i3
has also a special GUI customization, that could be merged with the utilities from mail
(same for i3
settings, some advtrains
user-settings, etc.). And without thinking about i3
or advtrains
, it is just that mail mod initialize a lot of utilities that are not intended to be used only with mail
mod, so why not debundle these directly ?
Many library projects fail because of trying to provide useful and generic stuff without really field testing it first, and when you fail once people will remember not to waste time with it again. Doesn't matter if you fix the issues.
Yes, but some have worked (e.g. GTK :wink:)
That's a bad comparison. The wrench mod was separated to make it easier to maintain, and because it could be used without technic, it made sense to make it available separate from the modpack.
Yes, and mail.get_color()
, ... can be used without mail
mod :slightly_smiling_face:
Btw I'm still waiting for getting the right to close this to release 1.4.
1.4 is waited for a long time, I move that to 1.5
Yo,
I initially planned this in my mind for 1.5.0, but as 1.4.0 is getting more and more "late" (that's a volunteer project at all), so I'm opening the issue right now and I did not set a milestone, to be discussed.
IMHO, we should the following stuff :
guitil
? (idk, that's not important lol)util/colors.lua
util/time_ago.lua
(used in Date tooltip) ?modname.get_color("color")
actual functionmodname.get_color({"color1", "color2"})
actual functionmodname.insert_widget()
=> could returns a formspec-escaped for "custom" widgets like highlighted box.settings
, or to not be too restrictive something likesettingz
?ui/settings.lua
util/settings.lua
storage.lua
modname.register_setting(dictionary)
modname.register_settings(list of dictionaries)
modname.get_setting(name, "setting")
exactly likemail.get_setting()
modname.set_setting(name, "setting", value)
exactly likemail.set_setting()
modname.reset_settings(modname)
All those dependencies of
mail
mod, all managed bymt-mods
, and for all I assume the "unofficial" role of (co-)maintainer.