Version: (using Devel) Installed from: Compiled sources The new File Copy dialog that sits in the status tray is very useful once one is familiar with it. The current behaviour is to show the File Copy dialog for a few seconds, then to hide the dialog in the system tray. However, there is no obvious indication that the file copy is continuing once the initial popup closes automatically after several seconds. Once a user is familiar with it's icon in the System Tray then the user will know to look there to see the progress of the Copy operation. But users unfamiliar with the icon (users new to KDE 4) will not know where to look, and may assume that the copy operation has failed. I should stress that many computer users are not familiar with many of the icons of their system trays. I suggest that during file transfers either the System Tray icon have a _very_ prominent animation or other effect, or to have a regular window as is the KDE 3 behaviour. The System Tray is usually understood to contain items that are running in the background and the Task Manager is usually understood to contain items that the user is doing at the moment. Because file copy operations are something that the _user_ is doing, and not a background computer process, this should be a Task Bar item. If it _must_ remain in the System Tray then please add an animation that makes it obvious that something is being done, such as a rotating or flashing icon with bright, contrasting colours.
*** Bug 181648 has been marked as a duplicate of this bug. ***
Using KDE 4.2. I agree with the reporter -- the fact that file-operation dialog disappears before the operation actually completes is bad thing. It makes user to think that operation is finished while it isn't. Even being an experienced user and knowing about such KDE4 behavior, I've got lost some files (I've deleted a zip archive before it was fully unpacked). Currently, on every file operation I need to click on system tray to re-show the copy dialog, because otherwise I couldn't see the moment when operation completes. Both newbies and experienced users need to know whether file operation is still running or already finished. Please consider at least one of the following things: 1. File operation dialog doesn't hide until operation completes (unless manually hidden by user). [or/and] 2. Bright animation in tray while some file operation running. And number of currently running operations is written on the animated icon. [or] 3. Global redesign for file operation dialogs. Thanks.
:) ha, that's a difference between pessimist and optimist -- when operation dialog disappears, first one thinks that operation failed and latter one thinks that operation completed :)
"that's a difference between pessimist and optimist" The I must be an optimist. :-) The disappering copy dialog(or all IO operation I might add) is very confusing: 1: You start a file copy process 2: A dialog telling the process status appears. 3: A few seconds later i disappears. -> and there you have it. The apperance of the dialog indicates that it started, so the DISapperance indicates that it ended. "But you just click the icon to view it again!" Yes, that is a possibility, but then you have to have that knowledge first, and int the meantime you may go around a do something foolish like moving lots of stuff to a USB stick, pull the stick out before the move process actually ended - and then what happens? My wife lost a ton of work doing just that.
@sasha: When the file transfer dialog of a 2 GB file transfer over the network closes in 10 seconds, it is reasonable to assume that the file transfer failed. A KDE developer recently mentioned this issue as one of the reasons of abandoning KDE for his wife's machine: http://qashapp.blogspot.com/2009/02/my-wife-gave-up-on-kde.html In the comments of that bug several new perspectives have arisen: 1) Many users are confused by the issue, though they seem to like the feature once they are made aware of it. A consensus seems to be to have a more visible, flashing or colourful icon in the system tray. I would recommend an animation of the dialog going to the system tray as well. 2) A user may think that the transfer is done, and then log out. This is a dataloss issue. In fact, the original blog post also mentions dataloss due to the issue. 3) (OT) They really don't like Kubuntu!
"A KDE developer recently mentioned this issue as one of the reasons of abandoning KDE for his wife's machine:" That would be me, but although I am a developer, I have never contributed code to KDE. (Not that I dont want to).
> Many users are confused by the issue, though they seem to like the feature > once they are made aware of it. A consensus seems to be to have a more > visible, flashing or colourful icon in the system tray. I would recommend an > animation of the dialog going to the system tray as well. [1] I agree that flashing/animated icon is good idea. It's a 70% of solving the issue. But just flashing/animated icon is not enough, imho. [2] Very often I do nothing during file operation, just look on the dialog -- and reasonless disappearance of the dialog that I'm looking onto, is very annoying. Idea A: An option to (permanently) enable/disable dialog auto-hiding while operation running. (And by default auto-hiding should be disabled.) Idea B: Dialog should hide not after 8 seconds, but when user click somewhere else. Just like "Recently plugged devices" currently works. I.e. you click on "Recently plugged devices" icon (or: start copying) -- devices dialog appears (or: copying dialog appears); and it doesn't disappears itself (unless copying finished); but if you click on another window or press Alt+Tab or press escape, dialog disappears (only the icon remains). Thus, if user needs to watch progressbar, he will not be annoyed with sudden disappearances, but if he wants to do something else, dialog will disappear. (As an extra sugar to "idea B", each dialog could have a pin "don't hide me", which will make the dialog remain visible even when user switched to some other app. This would be an IDEAL solution. Do you agree with me?)
P.S.: The numbering in my last message isn't related to the numbering in the Dotan Cohen's message. I just numbered the things that should be done ([1] = primary task, [2] = secondary task).
IMHO
This does not solve the issue, but it is related -- having a log for each app, so user could click in status bar (?) and see for k3b what went wrong, or in this case -- that file A was copied successfully, and B not.
@Maciej: That's Bug #182132 (also filed by me)
*** Bug 184170 has been marked as a duplicate of this bug. ***
*** Bug 187923 has been marked as a duplicate of this bug. ***
The current behaviour (trunk) seems a good improvement: the animation is very useful to show the "work in progress".
@Finex: I cannot run Trunk at the moment, but I will keep this bug nearby and close / add more info when I can get to a more updated system. Thanks.
Ok Dothan, don't forget to check it when you'll have the possibility to try 4.3 or trunk :-)
In trunk we have some of the things that are already suggested here: * animated spinner icon when jobs are running, with number before it showing how many total things there are and how many of them are completed. * animation when hiding or showing the jobs/notifications (well, any plasma dialog for that matter). smoothly sliding into the panel probably helps. * showing the job again when it completes, but using a different widget in a different extendergroup (well this last one is actually pending on review board) There's some work being done on the systray to hopefully improve the situation, but we're hesistent to add a config option for this. Personally I'd hate to disable auto hide alltogether. I know when I just started a job and I'd hate to have to do something to make it go away. I usually continue working while stuff copies and just like to be notified when it is finished. But we'll try to figure out a way to make everybody happy.
I agree with Rob: auto hide notification popups is a good thing (tm). Less clicks equals less distractions
Thanks for the update Rob. I will try to triage the new design soon, and when I do I will either close this bug or add comments regarding relevant usability issues. Thanks.
Smoothly sliding and having the icon animated will be a big help, but there's still the chance for misunderstanding from people like my mother and, in my case, it'll still be annoying. I've got two monitors and I ALWAYS like to leave my copy progress visible to I can glance at it. That means I always end up having to either click the icon twice or wait for the copy popup to hide itself and then click to get it back.
@Stephan Sokolow: thanks for providing that valid usecase. I will consider it. At the moment you can detach the job group and drop it somewhere else: new jobs will from that moment on also appear there.
I agree with Stephan Sokolow. In many situations users (me too) do nothing during a file operation, just wait for its finish. In this case we just watch the progress bars. And the fact that progress bars suddenly disappear, is annoying. Yes, animated icon helps a lot -- it lets the user (at least, the non-novice user) to understand that operations are still going. But the icon always shows to the user less information than popups do (i.e. time remaining, current speed, etc). So the role of animated icon is the following: it helps to avoid misunderstanding (at least, for non-novice users), but doesn't help to avoid annoyance of the fact that user need to click the icon almost each time.
Anyway, thanks to developers for the job that is already done.
*** Bug 185504 has been marked as a duplicate of this bug. ***
Hi there, Rob has recently marked my own bug report as duplicate of this one. Well, though it obviously relates, I'd rather share my thoughts here again. Reading this thread I've noticed that the major concern seems to be what rookie users might experience when the popup suddenly goes away. But there are implications for experienced users (like me, of course), too. It's early in the morning,so forgive me for just copying and pasting: > ... > However, I have followed KDE 4.2's call and switched from an > application oriented workflow to a more task based one, meaning that I > have abandoned my Kicker (Plasma bar, whatever) completely and work in > fullscreen apps now. All informations I need are displayed in playmoids, > which I bring to the foreground when I need it. > > This also affects my systray, which is now invisible most of the time. > > Dolphins new behavior now forces me to raise the plasmoids and click > on the minimized icon to get back the progress bar, which turns out to > be a major annoyance. How was that: fewer klicks, fewer distraction? ;-) > I reckon the easiest solution to be a checkbox in the options to > toggle the hiding behavior of the progress bar, so that it can be told > to stay on top all the time. > > Alternatively I could live with a tiny indicator inside Dolphin's UI > that tells me that a copy/move operation is still active. Maybe it > could unhide the progress bar as well, when clicked. > ... Orientation towards the unexperienced is nice, yes, but please keep in mind that not every KDE (Dolphin) user is really that braindead and needs (or even asks for) guidance. What's the use of a notification slowly swooshing into the Taskbar if I don't have one and all my swooshing effects are disabled because I don't want to buy a new Laptop to "enjoy" them? Cheerz, Martin
SVN commit 962610 by scheepmaker: Allow for configuring whether or not jobs and notifications should automatically hide after 6 seconds. BUG: 177708 M +3 -1 CMakeLists.txt M +54 -36 ui/applet.cpp A ui/autohide.ui WebSVN link: http://websvn.kde.org/?view=rev&revision=962610