Systray jobs

[Rob Scheepmaker]

On Friday 01 May 2009 21:53:04 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
> 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)

Yeah, that page would probably be the best fit, but still not perfect imo. But 
we can't just add a page for this simple option, and the notifications page is 
probably a worse fit then the autohide page. And +1 on the checkable items.

> > * 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 :)

Well, there is a 'clear jobs' link displayed in the completed jobs group that 
will remove all completed jobs there, so that helps. But that still requires 
interaction. And personally I feel 24 hours is a maybe a bit long. But maybe 
we could do something with the idea of Chani that items get moved to some long 
term log after a shorter while, and/or we don't expire completed jobs while 
the computer isn't in use?

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

Agreed, but I don't feel comfortable with adding public bits to the kjob api 
especially this short before the freeze. Though I think that when we go this 
road we should be able to provide a command that can be executed and not just 
connect signals/slots to the kjob like with suspend/resume, because after a 
reboot, this should still be working imo.

Regards,
Rob