Systray jobs

[Marco Martin]

On Friday 01 May 2009, Aaron J. Seigo wrote:
> 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

what it feels a bit weird to me about that page... shouldn't it be called 
"Manual hide" ?  because is more about items that the user decide to hide than 
about items that decide to hide themselves

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