SUMMARY When an InlineMessage contains a link it cannot be activated at all. Apparently regressed in https://invent.kde.org/frameworks/kirigami/-/merge_requests/1638 > Kirigami.InlineMessage { > text: xi18nc("@info","foo <link url='fake:open-details'>view detailed output</link>.") > onLinkActivated: (link) => { > console.log("link activated:", link) > } > } DrKonqi has a bunch of those and one critically important one for diagnostic data. STEPS TO REPRODUCE 1. click link 2. signal gets emitted with empty link string OBSERVED RESULT Links dont work EXPECTED RESULT Links work SOFTWARE/OS VERSIONS Operating System: KDE Linux 202502130256 KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: AMD Radeon RX 7800 XT ADDITIONAL INFORMATION InlineMessage contains a SelectableLabel. SelectableLabel contains derives the activated link from a HoverHandler https://invent.kde.org/frameworks/kirigami/-/blob/b2c2d1c86b98da27f348a06320d653a6eba842cc/src/controls/SelectableLabel.qml#L137 the HoverHandle is disabled https://invent.kde.org/frameworks/kirigami/-/blob/b2c2d1c86b98da27f348a06320d653a6eba842cc/src/controls/SelectableLabel.qml#L149 -> no hovered link -> no activated link
According to my investigation it's actually not the HoverHandler in the SelectableLabel, which is working just fine. It's that the hover and link opening handlers in InlineMessage itself are faulty, breaking the chain of upward signal propagation so that implementations with their own handlers never get the signals.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1729
Git commit b1e3a84e2a1f7f8b8c9718f01d1492781ac61bed by Nate Graham. Committed on 05/03/2025 at 14:33. Pushed by ngraham into branch 'master'. InlineMessage: fix link opening and hover handlers The Label and ActionToolbar occupy the same space, with the ActionToolbar being rendered last. This makes its own hover handling override that of the Label, causing the pointing finger cursor to not appear when hovering a link. There's nothing wrong with both occupying the same space, but we do need the Label to be rendered on top so its hover handling takes precedence. FIXED-IN: 6.12 M +19 -18 src/controls/templates/InlineMessage.qml https://invent.kde.org/frameworks/kirigami/-/commit/b1e3a84e2a1f7f8b8c9718f01d1492781ac61bed
Re-opening as it the fix had to be reverted in https://invent.kde.org/frameworks/kirigami/-/commit/07bd6acece2392650a407f295169cfe8a055ce02 due to causing even worse issues with the ActionToolBar's buttons not being interactive. Basically the problem here is that we want a SelectableLabel and an ActionToolbar side-by-side, and both want to have the whole space, and both also need to be hoverable and clickable. This is a very tricky problem to solve.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1759
Git commit 82abc7690b79556499d5ae25b223ca358618c72f by Arjen Hiemstra. Committed on 07/04/2025 at 15:26. Pushed by ahiemstra into branch 'master'. controls: Fix link activation for text of InlineMessage Rather than stretching both the label and toolbar across the entire inline message, use implicit width for both, unless either would become larger than the InlineMessage width. Most importantly, since the toolbar only takes space that is not used by the text, this avoids links in the text not working correctly. M +6 -9 src/controls/templates/InlineMessage.qml https://invent.kde.org/frameworks/kirigami/-/commit/82abc7690b79556499d5ae25b223ca358618c72f