Hi Michael,
the whole concept of "extended tooltips" should be reconsidered.
Currently when you enable the extended tooltips, you loose the short
tooltip and are presented with a wall of text instead.
There is bug 125999
<https://bugs.documentfoundation.org/show_bug.cgi?id=125999> which
suggests to merge them together and display them as
---------------------
! << Short tooltip >> !
! Very loooong !
! describing tooltip. !
---------------------
Essentially your number 3), but there’s no need to split them up — just
show everything. The short tooltip in the first line should be bold, the
rest in normal style.
Regards
Samuel
Am 05.11.25 um 13:52 schrieb Michael Weghorn:
LibreOffice supports extended tooltips for widgets. If enabled, those
are shown instead of the standard tooltip when mouse-hovering over a
widget.
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")
