Summary: | JuK starts off miminized to tray, which is confusing--no main window is seen | ||
---|---|---|---|
Product: | [Applications] juk | Reporter: | Michael <kde> |
Component: | general | Assignee: | Scott Wheeler <wheeler> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | mpyne, shubham.chaudhary |
Priority: | NOR | ||
Version: | 3.9 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/juk/61e5fc8d9b437f9ec8efa507ea69de6e3a37e517 | Version Fixed In: | 4.12 |
Sentry Crash Report: | |||
Attachments: |
display system notification
display system notification |
Description
Michael
2013-03-16 11:03:11 UTC
I can confirm this bug, happens everytime. Using JuK Version 3.11 Using KDE Development Platform 4.11.2 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.
Is this solution satisfactory? Shall I open a review for this patch in review-board? 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. ;) 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. 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. 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.
Created attachment 82681 [details]
display system notification
Modified patch with KNotification
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. FIXED-IN:4.12 GUI: M +5 -0 juk.notifyrc M +7 -1 main.cpp http://commits.kde.org/juk/61e5fc8d9b437f9ec8efa507ea69de6e3a37e517 |