Explore using own menu implementation with curses

[svartkanin]

Currently archinstall is using simple-term-menu for rendering the menu on the tty. Although the library does its job, it is also somewhat limited on the possibilities beyond a simple menu display. Information can only be shown from a top to bottom approach and there is no way of utilizing other spaces on the screen to be more flexible.

An alternative approach could be to use curses, this would require a custom implementation of the existing menu capabilities but would then allow to add a lot more customization on top.

[codefiles]

I absolutely agree with this and was thinking the same thing.

[svartkanin]

I'll try to get started on some code, happy to collect any suggestions on how to use it flexibly.

[Torxed]

I'm throwing out this as a discussion not a must. But to me it feels like a good idea to completely disconnect the UI part into a archinstall-tui-curses repo if we go down this route.

As it would make it easier down the line to choose flavor of UI.

Would this be desired? As there's been numerous discussions about a GUI and that was treated this way.

They'd have archinstall as a dependency, thus belonging together but easier to separate?

[svartkanin]

So how would the tui then be integrated into archinstall? Repo or just a module will lead to a similar outcome probably as the tui needs to be initialised and the components then plugged in.

Maybe I'm missing a bigger picture here, what would the benefit be to have a different repo for it?

[Torxed]

Ideally the TUI could perhaps transit into doing from archinstall import X rather than from ..disk import X and utilize the core code more as a library rather than being entangled as it is today.

Having two repos would make things a bit more maintainable by allowing more administrative privileges to be distributed without giving access to everything. I've been dabbling with a similar idea for the translations, as there's numerous PR's for translations and they don't really have an effect on the core features. Giving support staff (usually the first entry into becoming a staff member in Arch, where the bulk of staff is) privileges to merge PR's on a translation repo would be pretty easy and a care free thing to do.

It's mainly just a structural change for making maintenance more diverse.

[svartkanin]

Let me try to unwrap that, the TUI would be a new standalone repo/library that will import archinstall and use the provided functions to then orchestrate the UI.

What would happen to the menu system in archinstall? Would that be thrown out and only have the core functionality in there, basically all core logic that is included in the

• Apply filesystem changes
• Perform installation

All other functionality is tightly coupled with the current menu system and only used to create the configuration that is then relevant for the above points.

Another question is archinstall allows anyone to scrript their own installer, by removing the UI part from archinstall that means that people who want to script things will need to change their setup to use the TUI repo/lib instead.

Looking at the development environment, I see that creating a completely separate repo will cause a lot of friction for devlopers and contributors that want to get onboarded. It will be more complex to setup and get people involved.

For the translation part, it's a bit of a isolated component as it doesn't have anything to do with the functionality of archinstall per se, and contributors do not even have to be technical or developers therefore it would be feasable to extract that to a new home.