Bug 389663

Summary: kget window does not open under wayland
Product: [Applications] kget Reporter: Tim Van den Langenbergh <tmt_vdl>
Component: UIAssignee: KGet authors <kget>
Status: RESOLVED FIXED    
Severity: normal CC: andrius, simonandric5, wbauer1
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 17.12.2
Sentry Crash Report:
Attachments: terminal output of kget under wayland

Description Tim Van den Langenbergh 2018-01-30 22:59:59 UTC
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.
Comment 1 Wolfgang Bauer 2018-01-31 20:09:16 UTC
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.
Comment 2 Tim Van den Langenbergh 2018-01-31 20:11:03 UTC
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.
Comment 3 Wolfgang Bauer 2018-01-31 20:27:41 UTC
(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... ;-)
Comment 4 Wolfgang Bauer 2018-02-05 20:39:33 UTC
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.
Comment 5 Wolfgang Bauer 2018-02-05 21:01:36 UTC
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
Comment 6 Andrius Štikonas 2018-02-14 20:54:54 UTC
There is now a proper fix under review in

https://phabricator.kde.org/D10518

Both restoring and hiding window should work.
Comment 7 Tim Van den Langenbergh 2018-02-18 00:05:41 UTC
Tried it, it works fine, that was amzingly fast. Thank you very much.
Comment 8 Andrius Štikonas 2018-02-20 14:37:22 UTC
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?
Comment 9 Wolfgang Bauer 2018-02-20 23:07:34 UTC
(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.
Comment 10 Andrius Štikonas 2018-02-20 23:09:20 UTC
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.
Comment 11 Wolfgang Bauer 2018-02-20 23:17:30 UTC
(In reply to Andrius Štikonas from comment #10)
> Hmm, sorry, KStatusNotifierItem. Typo...

KGet already uses KStatusNotifierItem.
Comment 12 Andrius Štikonas 2018-02-21 00:03:12 UTC
(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.
Comment 13 Wolfgang Bauer 2018-02-22 11:15:57 UTC
(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.
Comment 14 Andrius Štikonas 2018-07-15 11:06:16 UTC
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.
Comment 15 Wolfgang Bauer 2018-07-19 19:06:08 UTC
(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.
Comment 16 Andrius Štikonas 2018-07-19 19:56:30 UTC
(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+
Comment 17 Wolfgang Bauer 2018-07-19 21:08:09 UTC
(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...