Those PRs contain much more detailed information and also screenshots:
-
Qt UI:
-
NCurses UI:
-
Abstract UI:
-
Auto-wrapping feature (8 months later): libyui/libyui-old#165
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
- 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
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
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.
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.
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
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.
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.