Systray jobs

[Aaron J. Seigo]

On Friday 01 May 2009, Rob Scheepmaker wrote:
> * Auto hiding after the dialog with jobs and notifications get's
> automatically shown because one get's added. Currently this is hardcoded to
> 6 seconds, but there are quite some requests for having no auto hiding at
> all. I do  very much prefer autohiding, since you can continue working
> without having to close the popup manually when you start a longer running
> job. However, some people prefer no autohiding because they have their
> systray on a second monitor for example, so it doesn't really block their
> workflow. I therefore suggest adding a config option to the systray, to
> configure the autohiding time.

do we really need to have it configure the autohide time? or could it simply 
be a boolean on/off? 

as for where this would belong, my thoughts are that the Autohide page would 
make the most sense (and that he icon list there could be replaced with a list 
of checkable items, but that's a separate issue)

> * I don't like having to clear the list of completed downloads whenever I
> want a clean systray, and I think having the completed job extenderitems
> automatically destroyed after a certain time could make sense. However,
> what would be a sensible timelimit? 5 minutes? and hour? a day? I would
> also hate if it would require an extra config option. This is the issue I'm
> most uncertain of.

thinking about it here, i'm not sure there's really any "perfect" time at all; 
it really varies for me depending on what i'm doing.  an autoclear after 24 
hours is probably safe enough though. a "clear jobs" entry somewhere would be 
cool :)

> * Currently we just look at the second label, check if that's a filename
> (all kio jobs have destination as second label, if there is a destination),
> and use that to provide the possibility of opening the completed file. To
> do this properly so an action can be provided for every kjob, this
> possibility needs to be added to kjob/jobview dbus interface, but I think
> that's more something for 4.4. Anyway, this approach has the following
> problems:
>
> ** when copying multiple files, you will only be able to open the file last
> copied. Possible solution here would be to check if there amount of files
> copied is bigger then 1, and provide opening the destination folder instead
> of the file in that case.

maybe the app should provide the action name and the tray just show the entry 
for it, then call back into the job to execute it. that would be more generic 
than just "open this file"?

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090501/f4f32583/attachment.sig