Bug 1219535
| Summary: | [RFE] Update fields parser / renderer to handle units properly and in a locale-sensitive manner. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Einav Cohen <ecohen> | ||||
| Component: | RFEs | Assignee: | bugs <bugs> | ||||
| Status: | CLOSED DEFERRED | QA Contact: | Lukas Svaty <lsvaty> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | --- | CC: | bugs, lsurette, mgoldboi, srevivo, ykaul | ||||
| Target Milestone: | --- | Keywords: | FutureFeature, Improvement, UserExperience | ||||
| Target Release: | --- | Flags: | ylavi:
ovirt-future?
ylavi: planning_ack? ylavi: devel_ack? ylavi: testing_ack? |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-04-01 14:47:31 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | UX | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1213766 | ||||||
| Attachments: |
|
||||||
once our dialogs will adopt the PatternFly styling, we will have a built-in way for adding prefixes/postfixes for fields, if necessary (see http://i.imgur.com/NM2Urzw.png - taken from [1]). PatternFly may offer additional/different guidelines regarding units, in any case - we should follow PatternFly's guidelines. [1] http://getbootstrap.com/css/#forms after discussing with Alexander: description (comment #0) makes no sense if you take localization into account. For several locales units are on the left instead of the right. So if we force all the units to be on the right we have just made the application unusable for those locales. We have infrastructure in place already to automatically render values with their units inside the widget and parse them when the user enters them. Unfortunately we are not actually using this infrastructure. We need to make the fields [that right now do 'label (unit)'] use the infrastructure so users can type the value and use the renderer to properly display the value and the parser to figure out the intent of the user. For instance the MB/GB/TB example used. Default the unit in the parse to GB. So if the user enters 10, they mean 10GB. But also allow the user to enter 10TB and have the parser figure out that means 10000GB. Then have the renderer update the displayed value to 10000GB. If we properly define the renderer and the parser all that is automatically done by the infrastructure. This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly ok, closing. Please reopen if still relevant/you want to work on it. ok, closing. Please reopen if still relevant/you want to work on it. |
Created attachment 1023156 [details] screen-shots: units we have a couple of places in the GUI that include (typically) numeric fields which have their units mentioned as part of the field label (i.e. on the left-hand side of the field itself), rather than on the right-hand side of the field. from a graphical design perspective, it is better to have these units on the right-hand side of the field. this BZ was opened in order to track this change from a ui infrastructure perspective.