Bug 1161630 - [libyui] Non-intuitive ncurses interface in yast2 sysconfig
[libyui] Non-intuitive ncurses interface in yast2 sysconfig
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/oM61NSm9
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-01-23 06:30 UTC by Martin Liška
Modified: 2022-09-22 15:09 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.