Skip to content

Instantly share code, notes, and snippets.

@shundhammer
Last active February 22, 2022 16:38
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save shundhammer/069004d1c8e8e002917b295ce123c697 to your computer and use it in GitHub Desktop.
Save shundhammer/069004d1c8e8e002917b295ce123c697 to your computer and use it in GitHub Desktop.
Limitations of the ItemSelector / CustomStatusItemSelector YaST UI Widget

Limitations of the ItemSelector Widget

Original PRs

Those PRs contain much more detailed information and also screenshots:

Original Intended Use

Have a scrollable selection widget that has for each item:

  • A title
  • A descriptive text with potentially multiple lines
  • An optional icon
  • Single or multi selection

First extension: CustomStatusItemSelector

  • Custom states, not only on or off
  • A custom icon (Qt) or status Text (NCurses) for each status
  • Status 0 corresponds to "off",
  • status 1 corresponds to "on",
  • status 2..n are completely custom and application-defined

Limitations

Those limitations were all agreed upon and accepted when we started it:

  • No auto-wrapping, in particular not for the longer descriptive text
  • No RichText / HTML
  • The description is optional, but even then there will be one empty separator line between each item in NCurses

Overcoming the Limitations

Auto-Wrapping

Qt

Just set QLabel::setWordWrap( true ) for the description QLabel for each item.

https://doc.qt.io/qt-5/qlabel.html#wordWrap-prop

The price of that is that the widget can no longer determine its initial preferred size since now it can trade less width for more height and vice versa. That means that the widget would need to be forced to a certain size with our usual MinSize() / MinWidth() / MinHeight() widgets like similar scrollable widgets. That tradeoff should be acceptable enough.

NCurses

In NCurses that's much harder. It might be possible, though: For each item, use the NCWordWrapper class that was created for auto-wrapping YLabel / YQLabel / NCLabel widgets to word-wrap the description into the desired width, then query the NCWordWrapper how many lines that needs, then insert that number of description lines into the (NCTable based) NCurses widget as items with each wrapped line of that NCWordWrapper result.

That's not very elegant and probably quite wasteful in terms of performance, but doable.

RichText / HTML

Qt

Use the description QLabel's setTextFormat() to explicitly set it to RichText format or rely on Qt's autodetection (and make sure to add some markup in the Ruby part).

https://doc.qt.io/qt-5/qlabel.html#textFormat-prop

NCurses

This would require quite some refactoring to extract the libyui-ncurses RichText formatting into a separate class for a similar approach to auto-wrapping above: Render to memory (i.e. to a multi-line string), count the lines of the result and then add line by line of that result to low-level items (sub-items of the real items).

This is possible, but risky, and it will be a larger job.

After a look into the NCRichText widget, that does not look like a viable option.

@ancorgs
Copy link

ancorgs commented Feb 22, 2022

To be honest, I don't think that adding the inline descriptions (even if we can fix the RichText + break-line problems) would be the right solution for 15.4. It brings its own problems, specially taking into account we have around 20 items in the registration screen, potentially more. And reading this gist, the changes in implementation look to me risky enough to discard it for 15.4.

Unfortunately there is no time to completely rethink the whole screen with an alternative approach (likely not based on a long scrolled list of tri-state checkboxes that change dynamically on every action of the user). So if we do something for 15.4, it must be something that represents a smaller change compared to the current UI. Basically something that looks & feel the same but that improves the possibilities regarding theming and that reduces the usability problems (like crazy scroll jumps).

@shundhammer
Copy link
Author

shundhammer commented Feb 22, 2022

I agree with your assessment of this in time for 15-SP4.

But the usability problems of the existing approach that basically does web programming in our YRichText widget will remain for the forseeable future; that widget was never intended for that, and it's stretched beyond its limit already.

There is a reason why after years and years of the same neverending stream of complaints about it, back in the early 2000s we decided to abandon our half-assed approach of the software selection in YCP using the available UI widgets and writing dedicated high-level widgets for it; first for Qt only with the intent of simply not offering that level of luxury for NCurses, later for NCurses as well (but more as a matter of pride of the NCurses UI maintainer back then than for rational reasons). And gone were the complaints, basically forevermore.

The add-on selection is on a similar level of complexity, and of course it brings back the same type of problems that we had back then: The YaST UI widgets are not intended for that level of fine control. They are meant to greatly simplify UI development, and that comes at a cost: Losing fine control.

I actually question the wisdom of putting that much luxury into that add-on handling. It's reinventing software patterns on a different level, and that means of course duplicating all the functionality that we already have in the YQPatternSelector / YQPackageSelector.

Yet, if we really need that, we should stop mucking around on the UI amateur level and deliver a professional solution; and AFAICS that means writing a dedicated high-level widget for that purpose, very similar to the YQPatternSelector, and then think hard if we should really offer the same level of fine control for those 3% of users who really prefer the NCurses UI (for whatever reason).

I find it hard to understand that we even consider a very basic installer like that new D-Installer where we throw away everything to offer basically no fine control at all (just the absolute basics), yet we are adding more and more overengineering to the existing installer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment