Bug 1161630

Summary: [libyui] Non-intuitive ncurses interface in yast2 sysconfig
Product: [openSUSE] openSUSE Tumbleweed Reporter: Martin Liška <martin.liska>
Component: YaST2Assignee: YaST Team <yast-internal>
Status: RESOLVED WORKSFORME QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: ancor, locilka, martin.liska
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://trello.com/c/oM61NSm9
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Martin Liška 2020-01-23 06:30:34 UTC
When having the focus in Configuration Options, I would expect ENTER will expand an option subtree. Using '+' seems to me quite non-intuitive. Moreover, I would expect Description will be opened right I change focus to a different item in the Options list.
Comment 1 Ancor Gonzalez Sosa 2020-01-23 12:03:22 UTC
(In reply to Martin Liška from comment #0)
> When having the focus in Configuration Options,

Just to be 100% sure. You mean the left tree, isn't it?

> I would expect ENTER will expand an option subtree. Using '+' seems to me
> quite non-intuitive.

But ENTER is the same than clicking "ok" in most YaST dialogs, making this one different from the rest would be even more counterintuitive.

And apart from using "+" and "-", you can also use the right and left arrows, which is in my opinion the most intuitive option (since you are using the up and down arrows to move through the tree).

> Moreover, I would expect Description will be opened right I change focus to
> a different item in the Options list.

That's how it works for me... unless I'm misunderstanding something. Everytime a move the focus in the left tree to a different tree element, the right part of the interface changes to show the corresponding form.

In short, we must be describing different parts of the interface. Can you try to explain your problems a little bit more precisely? Maybe with some screenshots or video?
Comment 2 Ancor Gonzalez Sosa 2020-01-23 12:11:29 UTC
(In reply to Ancor Gonzalez Sosa from comment #1)
> 
> In short, we must be describing different parts of the interface. Can you
> try to explain your problems a little bit more precisely? Maybe with some
> screenshots or video?

Or are you talking about the text-bases ncurses interface?

If that's the case, all you mentioned indeed applies... but I got confused by the "GUI" word in the summary (the "G" is for "graphical" so I assumed you were talking about the Qt interface, not the text one).
Comment 3 Martin Liška 2020-01-23 12:22:34 UTC
(In reply to Ancor Gonzalez Sosa from comment #2)
> (In reply to Ancor Gonzalez Sosa from comment #1)
> > 
> > In short, we must be describing different parts of the interface. Can you
> > try to explain your problems a little bit more precisely? Maybe with some
> > screenshots or video?
> 
> Or are you talking about the text-bases ncurses interface?
> 
> If that's the case, all you mentioned indeed applies... but I got confused
> by the "GUI" word in the summary (the "G" is for "graphical" so I assumed
> you were talking about the Qt interface, not the text one).

Ah yes, sorry. I meant the ncurses interface.
Comment 4 Stefan Hundhammer 2022-09-22 15:09:25 UTC
After a huge change in that whole area 2 years ago (about around the time when you wrote this bug), I had to look this up. See also

https://github.com/libyui/libyui/blob/master/libyui-ncurses/doc/nctable-and-nctree.md


https://github.com/libyui/libyui/blob/master/libyui-ncurses/src/NCTree.cc#L367-L380

    switch ( key )
    {
	// KEY_SPACE is handled in NCTreeLine::handleInput
	case KEY_RETURN:

	    if ( notify() )
		return NCursesEvent::Activated;

	    break;
    }


So in short, the [Return] key is already consumed by those NCTree widgets for cases where you need to "activate" a tree item; i.e. where you select an item from a tree to do something with it in an associated / connected other view; the same thing as a double-click in the Qt version.

For example, in the device tree on the left side of the partitioner, you may want to edit the tree item under the cursor in the panel on the right side; that would be done with the [Return] key.

So that key binding already has semantics, albeit not in all instances of the widget. But of course we need consistency and to avoid surprising the user with unexpected behavior, so we don't want it to activate in some cases, and to just open or close a subtree in others.

Closing.