T-ui report and discussion

[juewuy]

Add your BUG report or Feature for T-ui here!
请在此处提交关于T-ui的BUG或者建议！

[juewuy]

The first bug ，on Xiaomi router @sofia-riese

The first bug ，on Xiaomi router [@sofia-riese](https://github.com/sofia-riese)

OKay, I will try my best to fix it as soon as possible. If you have any other questions about TUI, please feel free to ask.

@juewuy

The current issue encountered is: automatic line breaks splitting characters cause color codes to be lost or become ineffective.

I have resolved this issue by refactoring the content_line function. However, the refactored version utilizes syntax or features specific to Bash.

To maintain maximum compatibility, I haven't yet figured out how to fully convert it to a POSIX-compliant version.Is it acceptable that the script relies on Bash-specific functionality?

@juewuy

The current issue encountered is: automatic line breaks splitting characters cause color codes to be lost or become ineffective.

I have resolved this issue by refactoring the content_line function. However, the refactored version utilizes syntax or features specific to Bash.

To maintain maximum compatibility, I haven't yet figured out how to fully convert it to a POSIX-compliant version.Is it acceptable that the script relies on Bash-specific functionality?

Alternatively, this part of the code could be implemented in another high-level programming language (such as Golang), and then compiled into a binary file for use, thus solving the cross-platform issue. What's your opinion?

[juewuy]

@sofia-riese Sorry, this is not acceptable. Compatibility with ash is mandatory.

If there is no good solution at the moment, we can put this aside for now and revisit the necessity of automatic line wrapping after the localization work has progressed further.

@sofia-riese Sorry, this is not acceptable. Compatibility with ash is mandatory.

If there is no good solution at the moment, we can put this aside for now and revisit the necessity of automatic line wrapping after the localization work has progressed further.

Got it.

I might need an AI assistant to see if I can find a fully POSIX-compliant implementation.

I'll keep refining that section of the code and update here if there's any progress.

[juewuy]

@sofia-riese Alright, thank you for your efforts, and best of luck.

I'm pondering an issue: The “TABLE_WIDTH” parameter in the current tui_layout.sh script is fixed at 60. However, terminals running on mobile devices may have width limitations, leading to the layout issues shown in the image above.

To resolve this problem, the following approaches can be taken:

1. Modify the script to automatically detect the terminal's width. When the terminal width doesn't meet the “TABLE_WIDTH=60” requirement, dynamically adjust the “TABLE_WIDTH” parameter to fit the current terminal width.
   This approach is most user-friendly but poses development challenges and increases the script's code volume.

2. Provide prompts or instructions. If layout errors occur, advise users to manually reduce the terminal's font size to increase its width.

3. Inform users to directly modify the “TABLE_WIDTH” parameter in tui_layout.sh. This is the most direct approach but presents operational difficulty for users unfamiliar with Linux commands.

4. Add a function to modify the “TABLE_WIDTH” parameter within the existing main menu's function 8 “Tools & Optimization,” allowing users to adjust it themselves. I believe this method strikes a perfect balance between development difficulty and user-friendliness.

What do you think? @juewuy

[juewuy]

@sofia-riese Adding a UI customization feature is the optimal solution in terms of compatibility and extensibility. In fact, I am also considering how to continue providing user options that remain compatible with legacy UI versions in the future.

@sofia-riese Adding a UI customization feature is the optimal solution in terms of compatibility and extensibility. In fact, I am also considering how to continue providing user options that remain compatible with legacy UI versions in the future.

“providing user options that remain compatible with legacy UI versions”
Are you referring to an option to switch between the new and old UIs with a single click? That would mean maintaining two separate UI sets! Goodness gracious, I don't think that's a wise choice.

My current plan is this: if the modified tui_layout.sh functions properly, I'll begin gradually adapting other interfaces (which shouldn't take too long). During this transition period, both old and new UIs will coexist in versions until all interfaces are fully adapted.

What I'm more concerned about now is how the modified tui_layout.sh performs on other devices. Will it require excessive computation, potentially causing the interface display speed to fall short of the desired effect?

I need more feedback, whether positive or negative.
Why hasn't anyone else provided feedback on the new TUI yet...

[juewuy]

@sofia-riese I would not describe it as a legacy UI, but rather as a highly compatible, simplified variant. For example, this could involve removing the right-side vertical frame and disabling automatic line wrapping. In principle, as long as the TUI itself can function, this simplified version should always work correctly, albeit at the cost of visual aesthetics.

As for feedback, most users tend not to provide any as long as the core functionality works as expected. Even if there are minor display issues in certain interfaces, this is difficult to avoid. In practice, the only viable approach is to rely on time to gradually collect feedback.

@sofia-riese I would not describe it as a legacy UI, but rather as a highly compatible, simplified variant. For example, this could involve removing the right-side vertical frame and disabling automatic line wrapping. In principle, as long as the TUI itself can function, this simplified version should always work correctly, albeit at the cost of visual aesthetics.

As for feedback, most users tend not to provide any as long as the core functionality works as expected. Even if there are minor display issues in certain interfaces, this is difficult to avoid. In practice, the only viable approach is to rely on time to gradually collect feedback.

Got it.

I'll start adapting to other interfaces now.

Next, I will prioritize updating the TUI that has been adapted to support multilingual interfaces.

@juewuy HOLD ON!
Maybe there's a slight hiccup in our workflow sequence.

I'm currently trying to adapt menu.sh to the new TUI, but I'm running into a lot of trouble.
Since menu.sh is already multilingual, when adapting it to the new TUI—especially when adjusting sentences or their positions—I have to modify both corresponding .lang files. This effectively forces me to handle two tasks simultaneously: adapting to the new TUI and maintaining multilingual support. This makes the new TUI adaptation exceptionally difficult and significantly slows my progress.

Therefore, I need to coordinate with you. I hope you can first handle the multilingual adaptation for files that have already been adapted to the new TUI (e.g., 9_upgrade.sh). For other files not yet adapted to the new TUI, please ensure you only proceed with multilingual adaptation after I have completed the new TUI adaptation for them.

Regarding files already adapted for multilingual support, I will handle them as much as possible. However, this process will be considerably slower, and new sentences may be added during the adaptation to the new TUI, requiring your subsequent attention.

[juewuy]

@sofia-riese The TUI adaptation should not be this complex. Part of the work should be handled by the TUI layout itself, and another part should adapt naturally, rather than requiring manual adjustments for every individual piece of content. Otherwise, the workload becomes disproportionately large.

For now, I will prioritize files that have already completed TUI adaptation. However, this is not aligned with the original intent of the design.