+1 for encouraging and tracking this kind of code hygiene.

If I remember correctly in D18809 there was problem I had when using this style. There two tooltips would be visible and overlap eacht other (the tooltip of the listitem and the action tooltip). So this style doesn't work everywhere

Using QML tooltips as an attached property is discouraged

:/

QQuickToolTipAttached is a super light QObject that then creates the tooltip on demand, QQuickToolTip is a much heavier full QQuickPopup instance. Adding to every single button/delegate will add up significantly.

It also introduces a bug that popups can overlap

as they cannot inherit the default settings and times.

As in delay and timeout?

In T10873#186322, @davidedmundson wrote:

As in delay and timeout?

Yes.

In T10873#186322, @davidedmundson wrote:

QQuickToolTipAttached is a super light QObject that then creates the tooltip on demand, QQuickToolTip is a much heavier full QQuickPopup instance. Adding to every single button/delegate will add up significantly.

Is there any way to make the attached property version inherit the delay/timeout/etc values so we can get the best of both worlds?

Is there any way to make the attached property version inherit the delay/timeout/etc values so we can get the best of both worlds?

Not in Qt5.

Options are:

• Copy 2 lines
• Creating some KDEImport.Tooltip which is a lot of duplication, which arguably also solves the in-window vs real tooltip issue. Plasma has one somewhere which could be moved
• Make performance abysmal instantiating an entire dialog. Would be the hardest to migrate if we fix it in Qt6.

I think the simple solution would be to just add something to the units in Kirigami and Plasma, and have coding convention to use those units.

So still have to manually set the properties everywhere but take the values from external API instead of hardcoding.

Works for me.