On 7/24/20 10:14 PM, josef Reidinger wrote:

Hi dear YaSTies, after thursday UI meeting I spend part of today researching and thinking about our UI and do some brainstorming.

1. TUI use cases Beside known limited serial line and low memory systems, one another well known use case is WSL. We use TUI here for firstboot and on windows there is by default no X server. I think that WUI could really help here. What can be a bit like competition to us just on different level is IPMI and it is nowadays provided by BIOS or by WUI see https://www.thomas-krenn.com/en/wiki/Supermicro_IPMI_Configuration_through_B... And BIOS uses TUI.

Ok. IMHO, all this is compatible with the idea we discussed about a) not whole YaST is required to have a TUI and b) maybe only a few clients need to offer an advanced TUI.

2. terminal output of autoyast Well, to this idea brings me mentioning of readline and also usage of autoyast for more complex cases. Basically idea is to have just progress output for autoyast + error reporting ( so no semi automatic or stuff like this in autoyast ). And instead of TUI beside gui it can use simple terminal output e.g. using this quite nice library - https://github.com/shopify/cli-ui or tty-progressbar

That library looks very well! I think that "terminal output" feedback is a good idea for AutoYaST. IMHO, semi-automatic functionality only makes everything more complex, and maybe it does not offer a big impact in user benefits. For me, when I think in AutoYaST, I would like to have: a) An easy way to create the profile (no TUI here but GUI and WUI, and maybe GUI would be not needed at all). b) Be able to visually follow the installation progress, and in case of troubles, clear notes about what is wrong and how I can fix it.

3. WUI for autoyast config When I am thinking about replacing TUI by WUI and how to start, then I think ideal candidate is autoyast config UI because: a. current state is bad b. it is too much restricted by system where it runs ( e.g. just think about how much UI is affected by system architecture like not showing s390 options or not able to run it at all ) c. its output is just XML file, no system modification d. I have in mind nice use case of hosted autoyast config creator with maybe nice feature of using mksusecd and creating dvd including autoyast profile, that can be auto detected. So you download iso with your preconfigured autoyast profile. e. it is not used in installation

Yes, it looks like a good candidate to start with new ideas.

4. drag and drop in ncurses it should be possible as mouse support mouse down and also mouse up. See doc at https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/mouse.html BTW there is also quite nice quick intro to curses at https://www.2n.pl/blog/basics-of-curses-library-in-ruby-make-awesome-termina...

Working directly with curses gem does not look that hard. Thank you Josef for your research!

Josef

-- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 2020-07-24 23:14, josef Reidinger wrote:

4. drag and drop in ncurses it should be possible as mouse support mouse down and also mouse up. See doc at https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/mouse.html

Drag'n'drop is something that always just caused a lot of pain for me. There are useful applications for it, but anything in text mode is not among that. Back in the mid-90s when everybody as starting to use MS Excel for everything, drag'n'drop was en vogue. Remember OLE to embed other MS Office document snippets? A spreadsheet in a Word doc, a piece of graphics in an Excel spreadsheet? That stuff never worked well, much less as the user intended. Agreed, mouse support in general would be nice to navigate in an NCurses dialog. But drag'n'drop always was more of a nuissance than something useful: Stuff would unintentionally move from one place to another, and you'd spend more time restoring the mess you just created with a lot of "undo" steps. And "undo" is something we don't have, and something that would be really hard to implement in any useful generic way.

BTW there is also quite nice quick intro to curses at https://www.2n.pl/blog/basics-of-curses-library-in-ruby-make-awesome-termina...

Do you really want to program on that level? Remember, NCurses by itself does not have the notion of self-sufficient widgets. It only has very low-level windows; all it does is handle repainting. Anything beyond that you have to do on the application side, starting with simple key handling and scrolling. There isn't even anything like a simple input field. It's one thing to do something on the level of "tput" to make the output of scripts on stdout nicer; it's something completely different to have wizards and input forms, let alone more sophisticated stuff like trees or scrollable multi-column tables. Believe me, you don't want to go there as a normal application developer, much less as a YaST developer. This stuff is something that our UI layer abstracts from us. Try experimenting with that low-level stuff; it will be a healthy and most educational thing to do. You will learn to value the abstractions of our UI. ;-) Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org