On Friday 28 November 2008, Rob Scheepmaker wrote:
> * By default, don't automatically hide the popup, when it shows a running
> job. They're passive popups now (nice btw :)), which mean they aren't very
> intrusive anyways, and you can always close the popup with the right icon
> (which I notice now has a different background... smart little improvement,
> makes it clearer that somehow, that icon is special). Of course you can now
> always reopen the popup after it is hidden, but I think this automatic
> hiding could confuse some users ("where did my job go?"). The only way the
> popup should automatically be hidden, is whenever the extender becomes
> empty.i'm not sure i agree; i don't need something chugging away for minutes at a time on my screen just because it's working in the background. it should: * tell me when it starts * let me see what's going on when i wish to * let me ignore it when i wish to (which means defaulting to being unobtrusive) * tell me when it's finished or stopped due to an error > * Completed transfers should not directly be destroyed. Ideally, we > have a checkbox like the oldschool dialogs... "keep visible after job is > complete", or something to that extend. But considering string freeze and > whatnot, I think sensible behavior might be a timeout > (extenderItem->setAutoExpireDelay), of 5-10 seconds or something like that. > Always keeping it doesn't sound like a good idea to me, since that requires > the user to manually close every transfer window after each transfer which > can grow tiresome. By keeping it 10 seconds, and showing the popup the > moment a job finishes (if it isn't shown already), users can be quite > clearly informed that their job is ready. if they collapse down to a smaller size, have an "Open" button and a global "clear" button it should work. not unlike the Firefox download overview really. > * Some more info should be added. I'm thinking of adding 3 labels (all on > one line), to display totalSize, processedSize (both in Kb/Mb/Gb, not in > files), and current speed. All that information is provided by the > dataengine, and doesn't require any new strings, so I think it should be > ok. +1 > In the end, I'd love to see detaching to windows in 4.3, and some other =) > features too (opening the file/directly for example), but I think we'll > have quite sensible behavior with these 3 points implemented, and people > that still don't like it can change the behavior in the config file with > Andras' patch. +1 -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
