SUMMARY Browser does load the link, it's just it's window is not activated STEPS TO REPRODUCE 1. Open some link in konsole via it's "Open Link" context menu action. OBSERVED RESULT It seems like nothing happens. Actually, the link is opened in browser on background plane. EXPECTED RESULT Browser window with loaded link should bring to first plane. Operating System: Ubuntu 20.04 KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.73.0 Qt Version: 5.14.2
Confirmed, I believe this is a known issue but I don't know which bug is tracking it.
It is a known issue, there is no specification to do this. GTK use a custom one which doesn't help anyone.
So someone has to propose one and then all the compositors have to implement it?
and all toolkits
Is the custom GNOME implementation upstreamable, or would we/someone need to start from scratch?
*** Bug 427445 has been marked as a duplicate of this bug. ***
Can anyone please inform us about this bug? is there any work behind this? In fact, I personally would be fine if some hacks belonging to gnome, kde or wlroots (doesnt matter) were used to solve this problem.
Yes, a cross-desktop protocol is being worked on upstream: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50
*** Bug 432913 has been marked as a duplicate of this bug. ***
Since the Wayland protocol has been merged, this isn't blocked by anything anymore and we can implement support on our side.
I don't know why this was reopened. We know we don't support this yet.
Because with the activation protocol merged upstream, we now can, and having a bug report open to track that work is reasonable.
*** Bug 439567 has been marked as a duplicate of this bug. ***
*** Bug 440032 has been marked as a duplicate of this bug. ***
*** Bug 441866 has been marked as a duplicate of this bug. ***
This has changed a lot in 5.23. It won't fix everything at once, but leaving this open won't help with that.
I haven't noticed any changes in git master here. What specific changes need to be implemented to make it work in apps? Where should bug reports be filed?
OK, I have begun to file bug reports on individual use case which are still broken (for me, all of them): Bug 442264 Bug 442265 Bug 442266 Bug 442267 Bug 442268 Bug 442269 Should I continue? Is this useful?
>Is this useful? Not really. It's only useful if the receiving software is known to have activation support. Otherwise they need to be adjusted before we can start investigating any potential issues on our side.
So literally every app/toolkit needs to be changed to opt into the activation protocol? I fear that this is going to feel broken forever... :(
This bug is still reproducible on Plasma 5.23 beta even with KDE software. 1. open a text file with Kate via Dolphin 2. minimize Kate 3. open another text file with Kate via Dolphin Result: Kate is still minimized
KDE apps won't be fixed until activation support ia added into Qt. It's still in progress; see https://codereview.qt-project.org/c/qt/qtwayland/+/321246
*** Bug 444357 has been marked as a duplicate of this bug. ***
*** Bug 445128 has been marked as a duplicate of this bug. ***
*** Bug 448671 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #22) > KDE apps won't be fixed until activation support ia added into Qt. It's > still in progress; see > https://codereview.qt-project.org/c/qt/qtwayland/+/321246 It's merged, but I can still reproduce 5.24.80 on KDE Neon Unstable see #448671.
That's only in Qt6. Perhaps we should look into backporting it in our patch collection. It's a pretty huge change though, and stretches the definition of a bugfix. If fixing a bug required adding a major new feature, is it really a bugfix?
Strawberry music player is built against Qt 6 on Arch Linux and this bug is reproducible with it.
(In reply to Patrick Silva from comment #28) > Strawberry music player is built against Qt 6 on Arch Linux and this bug is > reproducible with it. Is it using Qt6 with the patch (which I guess is Qt6 master)?
I do not know. Which Qt version will include this fix/feature?
(In reply to Patrick Silva from comment #30) > I do not know. Which Qt version will include this fix/feature? Probably 6.3.0
Both the sending and receiving apps need to implement activation support, or be using a toolkit that does it automatically. It's not enough for one of the apps to be using a compatible version of Qt6; the other app that sent the activation request have to be using it, too. So currently this will only reliably work between Qt6 apps, or GTK4 apps, or between GTK4 and Qt6 apps. It sucks, I know. I'm somewhat baffled baffled by the fact that this wasn't, like, built into the core Wayland protocol. But it is what it is, and at least thanks To Aleix, we have it now.
Thanks for clarifying Nate. Probably we will have many duplicates of this bug in the next years.
Indeed. :(
(In reply to Nate Graham from comment #32) > It sucks, I know. I'm somewhat baffled baffled by the fact that this wasn't, > like, built into the core Wayland protocol. Just to understand the situation: Has this been built into the (core) Wayland protocol by now or if not, wouldn't it make sense to put it in there now, as of "better later than never"?
(In reply to postix from comment #35) > Just to understand the situation: Has this been built into the (core) > Wayland protocol by now or if not, wouldn't it make sense to put it in there > now, as of "better later than never"? So Wayland 2.0?
The activation protocol was done as an extension to the core protocol. I don't know if the core protocol itself is still open for changes. Someone who understands Wayland better than me would have to answer that question.
*** Bug 450926 has been marked as a duplicate of this bug. ***
*** Bug 451377 has been marked as a duplicate of this bug. ***
*** Bug 451504 has been marked as a duplicate of this bug. ***