Created attachment 110243 [details] terminal output of kget under wayland Like the description says, the main window of kget that shows the downloads and everything does not open when running KDE wayland session. The other windows (configuration, adding new download) do open normally. No problems under X11. Attached is output of a session.
You selected "unspecified" as version, can you please tell which version of kget you are using? See Help->About KGet in the menu. And I don't really understand "The other windows (configuration, adding new download) do open normally." How do you open them if the main window doesn't open? Please clarify. Thanks.
The about menu says it's version 2.95.0. I can open the other menus through right-clicking the system tray icon. Trying the restore option doesn't do anything, though.
(In reply to Tim Van den Langenbergh from comment #2) > The about menu says it's version 2.95.0. Ok, that's the KF5 version then. > I can open the other menus through right-clicking the system tray icon. > > Trying the restore option doesn't do anything, though. Ah. I will try to investigate. Unfortunately I cannot run Plasma on Wayland here because my distribution (Leap 42.3) doesn't support it yet. But I'll use an openSUSE LiveCD (Krypton) I suppose... ;-)
Well, I was able to reproduce it. But IMHO it isn't a bug in kget really. KStatusNotifierItem (part of the knotifications framework) should handle that, kget itself doesn't have any code for that. And as you wrote, it works fine in X11... I'll add a workaround to kget though.
Git commit ccefe1842cb34a530fa18cd878b7a7f56654d99c by Wolfgang Bauer. Committed on 05/02/2018 at 20:55. Pushed by wbauer into branch 'Applications/17.12'. TrayIcon: Explicitly show/hide the main window if requested Actually KStatusNotifierItem should handle this, but for some reason that doesn't work on Wayland, the window isn't opened when the user clicks on the tray icon or chooses "Restore" from the context menu. So do it explicitly as a workaround. FIXED-IN: 17.12.2 M +14 -0 ui/tray.cpp M +1 -0 ui/tray.h https://commits.kde.org/kget/ccefe1842cb34a530fa18cd878b7a7f56654d99c
There is now a proper fix under review in https://phabricator.kde.org/D10518 Both restoring and hiding window should work.
Tried it, it works fine, that was amzingly fast. Thank you very much.
Also fixed properly in KDE Frameworks 5.44. Unlike this workaround, that fix works for both minimizing/maximizing. @Wolfgang Have you thought about porting to KSystemNotifierItem? Maybe when this is done, just require min KF5 version to be 5.44 and remove all workarounds?
(In reply to Andrius Štikonas from comment #8) > Also fixed properly in KDE Frameworks 5.44. Good to hear! ;-) > @Wolfgang Have you thought about porting to KSystemNotifierItem? What is KSystemNotifierItem? > Maybe when > this is done, just require min KF5 version to be 5.44 and remove all > workarounds? Well, should definitely be done at some point I suppose (although I'm not really a big fan of "artificially" raising the version requirements without a good reason), but that was/is no option for a bugfix release anyway.
Hmm, sorry, KStatusNotifierItem. Typo... Well, KSystemTrayItem is in KDELibs4Support... (In reply to Wolfgang Bauer from comment #9) > (In reply to Andrius Štikonas from comment #8) > > Also fixed properly in KDE Frameworks 5.44. > > Good to hear! ;-) > > > @Wolfgang Have you thought about porting to KSystemNotifierItem? > > What is KSystemNotifierItem? > > > Maybe when > > this is done, just require min KF5 version to be 5.44 and remove all > > workarounds? > > Well, should definitely be done at some point I suppose (although I'm not > really a big fan of "artificially" raising the version requirements without > a good reason), but that was/is no option for a bugfix release anyway.
(In reply to Andrius Štikonas from comment #10) > Hmm, sorry, KStatusNotifierItem. Typo... KGet already uses KStatusNotifierItem.
(In reply to Wolfgang Bauer from comment #11) > (In reply to Andrius Štikonas from comment #10) > > Hmm, sorry, KStatusNotifierItem. Typo... > > KGet already uses KStatusNotifierItem. Oh, indeed. I just saw comments like // KSystemTrayItem should handle this, but that apparenly doesn't work on Wayland (bug 389663) and assumed it's not yet ported.
(In reply to Andrius Štikonas from comment #12) > Oh, indeed. I just saw comments like > > // KSystemTrayItem should handle this, but that apparenly doesn't work on > Wayland (bug 389663) Oops. No idea why I wrote KSystemTrayItem there... :-( Thanks for pointing that out and fixing the comments.
Maybe we can now revert this? The proper fix in knotifications 5.44 is now shipped by majority of distros. And if you want to test Wayland, you shouldn't be running older frameworks anyway.
(In reply to Andrius Štikonas from comment #14) > Maybe we can now revert this? I'll remove the workaround in the next bunch of changes I intend to make. Although, I don't think we should raise the minimum KF5 version just because of that. After all, it only affects Wayland. That's just my opinion though.
(In reply to Wolfgang Bauer from comment #15) > (In reply to Andrius Štikonas from comment #14) > > Maybe we can now revert this? > I'll remove the workaround in the next bunch of changes I intend to make. > > Although, I don't think we should raise the minimum KF5 version just because > of that. After all, it only affects Wayland. > > That's just my opinion though. This was also my opinion recently (not bumping). Not that it matters that much... There'll probably be more apps in 18.12 that depend on KF 5.44+
(In reply to Andrius Štikonas from comment #16) > This was also my opinion recently (not bumping). Not that it matters that > much... There'll probably be more apps in 18.12 that depend on KF 5.44+ True. But I'd rather wait for 18.12 with that, as you say. I.e. I'll do it for master, and then raise the minimum KF5 version...