Improve the role selection dialog

[dgdavid]

Context

Some time ago, the list of available roles grown enough to start not fitting in the role selection dialog. To fix it, the list was embedded in a scrollable RichText widget since libyui didn't offer a better option (see #671, bsc#1084674, bsc#1086187).

Trello card: https://trello.com/c/QjRVileZ

Current status

As part of a YaST UI improvements a new SingleItemSelector (see https://github.com/libyui/libyui/pull/148) has been added, which is a much better solution to display the roles list.

Changes

To update the role selection dialog using the new widget and removing the old code.

Tests

• Unit tests updated/adapted
• Also tested manually via driver update.

Screenshots

Click to show/hide

---

Before

ncurses	Qt

ncurses 80x25	ncurses 80x25 scrolling

---

After

ncurses	Qt

ncurses 80x25	ncurses 80x25 scrolling

Qt 1920x1080	Qt 2560x1600

[coveralls]

Coverage decreased (-0.1%) to 23.921% when pulling dca6922 on change-role-selector into 82939e0 on master.

[shundhammer]

Technically, LGTM. Just the one typo in the comment.
We might think about the forced line break; it makes perfect sense in NCurses, but I am not so sure about Qt. But that's more the icing on the cake than a deal breaker.
I'd also like to have @lslezak look at this; he might have more input.

[dgdavid]

Thanks so much for the review!

Technically, LGTM. Just the one typo in the comment.
We might think about the forced line break; it makes perfect sense in NCurses, but I am not so sure about Qt.

The thing is that some role description also force the horizontal scroll in Qt. I'll take an screenshot as soon as possible.

But that's more the icing on the cake than a deal breaker.
I'd also like to have @lslezak look at this; he might have more input.

Perfect!

[dgdavid]

I'll take an screenshot as soon as possible.

See the comment above

[dgdavid]

JFYI, I also tried

text.strip.gsub(/(.{1,#{max_line_length}})(?:\s|$)/, "\\1\n").chomp

but a benchmark reveal that scan and join allocates less memory than gsub and chomp. Exactly 1.11x less, although it will almost priceless for this use case...

[jreidinger]

hint, you can use existing code https://github.com/yast/yast-yast2/blob/66bc64d08c6ff017b88e3cff63fd02d78bbcf7f1/library/general/src/lib/ui/text_helpers.rb#L31

[lslezak]

I just noticed that this does not work well if a word is longer than the max. line length:

max_line_length = 10
text = "123456789012 123456789012 123456789012 123456789012"
puts text.strip.scan(/(.{1,#{max_line_length}})(?:\s|$)/).join("\n")

results in

3456789012
3456789012
3456789012
3456789012

i.e. some part is lost. But as using a word longer than at least 70 characters is not very likely we can live with that. But maybe it's worth adding a comment about this...

[dgdavid]

hint, you can use existing code https://github.com/yast/yast-yast2/blob/66bc64d08c6ff017b88e3cff63fd02d78bbcf7f1/library/general/src/lib/ui/text_helpers.rb#L31

Ops! I didn't know about it. And... I didn't took a look around 😓

Thanks!

[dgdavid]

@shundhammer, @lslezak

I re-tested it with the new changes (basically different max line lengths for textmode) and updated the most relevant screenshots in the PR description.

So, It's ready for a re-review, please.

[shundhammer]

Still LGTM from my side. @lslezak ?

[lslezak]

LGTM.

But as this is mainly about the UI it would be nice to see some screenshots here...

[lslezak]

I just noticed that this does not work well if a word is longer than the max. line length:

max_line_length = 10
text = "123456789012 123456789012 123456789012 123456789012"
puts text.strip.scan(/(.{1,#{max_line_length}})(?:\s|$)/).join("\n")

results in

3456789012
3456789012
3456789012
3456789012

i.e. some part is lost. But as using a word longer than at least 70 characters is not very likely we can live with that. But maybe it's worth adding a comment about this...

[lslezak]

Oops, the screenshots are already there... 🤦‍♂️

[dgdavid]

I just noticed that this does not work well if a word is longer than the max. line length:

Yep, I was trying to solve this problem in different ways, but as you said

using a word longer than at least 70 characters is not very likely

reason why I decided to not invest much time on it. And, for the same reason, I don't want to solve this with a loop...

[dgdavid]

Yep, I was trying to solve this problem in different ways, but as you said

using a word longer than at least 70 characters is not very likely

reason why I decided to not invest much time on it. And, for the same reason, I don't want to solve this with a loop...

That said, I didn't know (my fault, for not asking or taken a look) about the helper pointed out by Josef (see his comment)

So, I'm going to update the code to use it.

[dgdavid]

😫 😫 wrap_text helper don't respect the carriage returns inside the text 😞

[dgdavid]

😫 😫 wrap_text helper don't respect the carriage returns inside the text 😞

Anyway, as we agreed in IRC, I'm goint to merge this, then continue with #825 and finally improve the helper to support this use case.

[yast-bot]

✔️ Public Jenkins job #76 successfully finished
✔️ Created OBS submit request #748578

[yast-bot]

✔️ Internal Jenkins job #17 successfully finished
✔️ Created IBS submit request #205113