Bug 134561 - Styles Inspector should show natural attribute values
Summary: Styles Inspector should show natural attribute values
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Shivam Kumar Singh
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Styles_Inspector
  Show dependency treegraph
 
Reported: 2020-07-06 11:41 UTC by Heiko Tietze
Modified: 2021-02-09 13:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2020-07-06 11:41:29 UTC
Currently we show values (mostly) in internal values. For example ParaTopMargin = 212 or 0xff0000 in case of red colors.

Ideally we show the numeric values as in the UI (cm/in... as defined in locales), boolean as true/false (working), and colors as small filled rectangles.
Comment 1 Mike Kaganski 2020-08-12 09:15:01 UTC
https://listarchives.libreoffice.org/global/l10n/msg12884.html mentions SfxPoolItem::GetPresentation. IIUC, e.g. . It might be helpful for getting "natural", already translated values of properties. Note: the method returns the *value* of an item, not its name.

However, this needs a per-item handling. SI uses UNO properties, and there's no 1:1 mapping between UNO properties and SfxPoolItems: several UNO properties may actually be stored in a single SfxPoolItem. So we only can use those SfxPoolItems that directly correspond to related single UNO properties.

Additionally, we don't have the low-level access here to the SfxPoolItems, so we would need to construct temporary SfxPoolItems for generation of the presentation.
Comment 2 Caolán McNamara 2020-08-12 11:02:23 UTC
I should mention that in a lot of cases the implementation of a given GetPresentation is not very good, e.g. just a bare number value of an enum instead of a useful name
Comment 3 Heiko Tietze 2020-08-25 09:32:25 UTC
This one seems to be quite desirable, though raising importance is not really appropriate.