Bug 316832

Summary: JuK starts off miminized to tray, which is confusing--no main window is seen
Product: [Applications] juk Reporter: Michael <kde>
Component: generalAssignee: Scott Wheeler <wheeler>
Severity: minor CC: mpyne, shubham.chaudhary
Priority: NOR    
Version: 3.9   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 4.12
Attachments: display system notification
display system notification

Description Michael 2013-03-16 11:03:11 UTC
In a certain circumstance, launching JuK causes it to not appear to the user. Instead, only its tray icon is visible. The user has to first know that JuK is running, go to the JuK tray icon, left-click it, and then it will appear.

Reproducible: Always

Steps to Reproduce:
1. Finish using JuK by clicking on the window's close "X" button (upper-right corner).
2. Juk minimizes to tray icon, so right-click on tray icon and select Quit from the menu. JuK quits.
3. Now launch JuK from Kickoff/system start menu.
4. JuK does not appear to user as a window, but only as a tray icon. User needs to click this icon for JuK to appear.
Actual Results:  
JuK starts hidden in tray.

Expected Results:  
JuK should appear windowed, otherwise the user will be confused thinking it's not running.

JuK seems to remember the windowed state at exit. If JuK is not visible as a window, and the user quits JuK by right-clicking its tray icon, selecting Quit, then the next time JuK is run, it will not appear as a window, just a tray icon. The only way to have JuK appear as a window when it starts is to know to quit-by-tray-icon trick. It's not intuitive.

A suggestion would be to turn off the default "Dock in System Tray" setting so that JuK will behave in a more consistent manner to other programs: closing the program makes it fully quit while minimizing it keeps it in the background. For savvy users, the tray option would still be there to turn on.
Comment 1 Shubham Chaudhary 2013-10-02 17:08:59 UTC
I can confirm this bug, happens everytime.
Using JuK Version 3.11
Using KDE Development Platform 4.11.2
Comment 2 Shubham Chaudhary 2013-10-03 22:53:43 UTC
Created attachment 82648 [details]
display system notification

A very simple solution to this problem.
Display a notification to the user stating that, JuK is indeed running and docked in system tray.
Comment 3 Shubham Chaudhary 2013-10-03 23:00:24 UTC
Is this solution satisfactory?
Shall I open a review for this patch in review-board?
Comment 4 Michael Pyne 2013-10-03 23:33:27 UTC
No solution that utilizes running a shell script would be acceptable here. Instead a message could be popped up directly from the C++ code, probably using KNotification (see http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKNotification.html)

One thing I'd like to consider is that we should not popup a notification on "session restore", but only when Juk is started normally.

There are bonus points if you can arrange for having someone trying to run JuK when it's already running to show that popup. ;)
Comment 5 Michael 2013-10-04 06:42:55 UTC
Help me to understand the rationale behind this feature whereby the user runs JuK and yet the user only has a small icon next to the clock to interact with.
Comment 6 Michael Pyne 2013-10-05 00:26:10 UTC
The rationale is approximately that not every action a user takes requires a flashing banner in response. Many users startup JuK and use one of the global keyboard shortcuts to start playback for instance.

However I agree that it can be confusing for someone who has not chosen this behavior, so it would make sense that even if a user selects the option to "Dock in the System Tray", that a notification is shown on subsequent startups as a gentle reminder. This notification could have a "Don't ask again" checkbox (if I understand KNotification correctly).

But in the case of a session restore, imagine if every application in the session were to display a separate notification when the user restores their session. The notification area would be quite noisy, and for no reason, as the session would merely be approximately how the user left it when they logged out.
Comment 7 Michael 2013-10-05 06:22:52 UTC
When I do computer training, people tend to be so tunnel vision focused and unaware they miss pop-up notifications, unless it appears front-and-center in the screen. It's made me realize that not everyone sees the computer the way I do, who is not daunted by computers and doesn't feel afraid that it's going to pull some surprise on them. Many people are daunted, especially the ones I bring to KDE on Linux.

> Many users startup JuK and use one of the global keyboard shortcuts to start playback for instance.

I can see that some seasoned users would use global keyboard shortcuts to start playback, yet there needs to be an existing proficiency with JuK to understand it.

For people who first use JuK, like myself and my friend included, we both were confused and stopped using it for awhile because "it didn't launch the second time" (it actually did, but we didn't see the icon). 

I feel frustrated that this is the default behavior as it's inconsistent with 99% of the rest of the KDE/Gnome application behavior that I'm familiar with. It requires a new cognitive model for how programs operate: "JuK doesn't go away when I close it. It's not in the taskbar either, like other programs. It's this little icon, and if I forget to quit it by it's right-click menu, then it can seem that it hasn't opened when I next start it." It's a lot to internalize.

It seems to me that the default behavior should model other applications in that clicking the X button quits the program immediately. Subsequently running JuK causes it to display as a window. This is safe. This is known. There are no surprises. There is no chance a user is going to say, "JuK didn't work the second time" or "I didn't notice a little pop-up notification" because of their tunnel vision.

I can see that as the user develops more proficiency and gains confidence with JuK they will explore the menu options and see that there is an option to keep it in the tray after click the X.

A new suggestion would be that when the user chooses the "Dock in System Tray" menu option, a KDialog pops up to tell them where they can find JuK and that the next time they run it, it will only be accessible from the tray icon. That way it's all clear and up front; there's no assuming the user knows anything.
Comment 8 Shubham Chaudhary 2013-10-05 22:23:57 UTC
Created attachment 82681 [details]
display system notification

Modified patch with KNotification
Comment 9 Michael Pyne 2013-10-06 22:52:52 UTC
Git commit 61e5fc8d9b437f9ec8efa507ea69de6e3a37e517 by Michael Pyne, on behalf of Shubham Chaudhary.
Committed on 06/10/2013 at 22:32.
Pushed by mpyne into branch 'master'.

Notify the user that JuK is docked on startup.

We show a simple notification if the user starts up JuK and it is set to
dock in the systray on startup (as otherwise the user may wonder why it
didn't open up). Although a "Do not show again" checkbox is not possible
with KNotification, it is possible to remove this additional
notification by going to "Application and System Notifications" in
System Settings to manage "Juk music player" application notifications.

We do *not* show a notification if a session is being restored to avoid
noise, however JuK will show the main window if the user tries to start
it up again after it's already running, so this should be OK.

Thanks to Shubham Chaudhary for the bugfix (you're been marked as the
patch author), and Michael for reporting the bug.

This bugfix adds new strings so it cannot be backported. It will show up
first in KDE SC 4.12.

M  +5    -0    juk.notifyrc
M  +7    -1    main.cpp