Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

De-bundle unspecific stuff #146

Open
Athozus opened this issue Apr 15, 2024 · 7 comments
Open

De-bundle unspecific stuff #146

Athozus opened this issue Apr 15, 2024 · 7 comments
Assignees
Labels
Cleanup Cleanup of bad code or other redundant/unnecessary stuff Help wanted Extra attention is needed
Milestone

Comments

@Athozus
Copy link
Member

Athozus commented Apr 15, 2024

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 :

  • GUI helpers
    • Name : maybe a combination of "GUI" and "Util" => guitil ? (idk, that's not important lol)
    • Depends : none
    • Stuff to be moved :
      • util/colors.lua
      • Some custom widgets like the highlighted box (using in settings/about)
      • util/time_ago.lua (used in Date tooltip) ?
    • Interaction :
      • modname.get_color("color") actual function
      • modname.get_color({"color1", "color2"}) actual function
      • modname.insert_widget() => could returns a formspec-escaped for "custom" widgets like highlighted box.
  • Settings
    • Name : simply settings, or to not be too restrictive something like settingz ?
    • Depends : GUI helpers just above
    • Stuff to be moved :
      • ui/settings.lua
      • Few components of util/settings.lua
      • Way it stores in storage.lua
    • Interaction :
      • modname.register_setting(dictionary)
      • modname.register_settings(list of dictionaries)
      • modname.get_setting(name, "setting") exactly like mail.get_setting()
      • modname.set_setting(name, "setting", value) exactly like mail.set_setting()
      • modname.reset_settings(modname)

All those dependencies of mail mod, all managed by mt-mods, and for all I assume the "unofficial" role of (co-)maintainer.

@Athozus Athozus added the Cleanup Cleanup of bad code or other redundant/unnecessary stuff label Apr 15, 2024
@Athozus Athozus pinned this issue Apr 15, 2024
@Athozus Athozus added the Help wanted Extra attention is needed label Apr 15, 2024
@Athozus Athozus self-assigned this Apr 15, 2024
@BuckarooBanzay
Copy link
Member

are those functions/features already used elsewhere?

@Athozus
Copy link
Member Author

Athozus commented Apr 18, 2024

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 ?

@S-S-X
Copy link
Member

S-S-X commented Apr 19, 2024

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.

@OgelGames
Copy link
Contributor

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.

@Athozus
Copy link
Member Author

Athozus commented Apr 20, 2024

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 😉)

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 🙂

@Athozus Athozus added this to the 1.4.0 milestone Jun 7, 2024
@Athozus
Copy link
Member Author

Athozus commented Jun 7, 2024

Btw I'm still waiting for getting the right to close this to release 1.4.

@Athozus Athozus modified the milestones: 1.4.0, 1.5.0 Aug 5, 2024
@Athozus
Copy link
Member Author

Athozus commented Aug 5, 2024

1.4 is waited for a long time, I move that to 1.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cleanup Cleanup of bad code or other redundant/unnecessary stuff Help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants