As GTK (like other toolkits) doesn't have any such concept, there's also no corresponding property that can be set/used for the widget in the .ui file.
Currently, the accessible description property ("AtkObject::accessible-description") is used instead.
As the name indicates, that one however has a different purpose.While the text used for the extended tip can be appropriate as an accessible description in some cases, that is often not the case (see examples at the bottom).
Therefore, I think it would make sense to separate the two, and no longer use the AtkObject::accessible-description property for the extended tip.
Potential alternatives I can think of:1) Ideally, introduce a new custom property (e.g. "extended-tip"). I'm not an expert here, but as I understand it after some reading, supporting custom properties in the .ui file editor (currently Glade, with Cambalache being a potential successor) and the GTK-based VCL plugins on Linux would probably require subclassing GtkWidget to create custom widget classes that support the new property. (LO's vcl and Qt implementations use a custom parser anyway, so evaluating a custom property wouldn't be a problem for those.)
2) (ab)use another existing GtkWidget property. "style" (in Glade: "Style Classes" in the "Common" tab, section "Widget Attributes") is one that supports a list of strings and having an unrelated "random" string value set in the list (e.g. "extended-tip: Some text for the extended tip.") probably at least shouldn't cause negative side-effects. At least when editing in Glade or Cambalache, these don't support entering multiline strings for that property, however.
3) Have both, the standard and the extended tooltip in the "tooltip-text" property in the .ui file, separated by some separator string, e.g.
<property name="tooltip-text">Normal Tooltip|||Some text for the extended tip.</property>
The weld::Builder/weld::Widget implementations could then split this into the standard and extended tooltips again.
While I'm not particularly thrilled about any of these options at the moment, I can't currently come up with a better idea. 3) currently seems like the best option to me.
Do you have any thoughts or alternative suggestions?To avoid having to manually review all existing values for AtkObject::accessible-description in case of such a split, one approach could be to still fall back to the accessible description if no extended tooltip was explicitly set. (Nothing would change from a user perspective initially, but things can then be adjusted as needed on a case-by-case basis over time.)
Examples where using the accessible description property is problematic: https://bugs.documentfoundation.org/show_bug.cgi?id=157633("NVDA screen reader doesn't announce Word Count dialog content when it opens")
https://github.com/nvaccess/nvda/issues/19155("LibreOffice Writer. When spell check is opened or moves to a new word, it gives a very verbose description of what spell check is")
OpenPGP_signature.asc
Description: OpenPGP digital signature
