[PATCH] A KJob jobtracker that uses kuiserver, or falls back to dialogs.

[Rob Scheepmaker]

On Thursday 04 September 2008 14:01:20 Rafael Fernández López wrote:
> The summing up goes as follows:
>
> - If you have the kuiserver plasmoid or kuiserver app running, use it (the
> service is registered on the bus). So this one is not a big deal.

And, I would say if this is the case (user having specifically started/added a 
kuiserver app/applet): always use it, even if the "seperate windows" option is 
chosen, since I fear it might otherwise confuse users, right? (I know I would 
be confused, if I've added the kuiserver applet, forgot to change the option 
in the kcm and left wondering why the kuiserver applet won't work)
Anyway with the patch as it is currently, this is already the case. :)

> - If the kuiserver plasmoid was added, the kuiserver app won't be brought
> up, since it will find out that there is another service registered with
> the same name.

Agreed.

> - If the kuiserver app was started, I think the kuiserver plasmoid should
> show no information, but a message informing about there is another
> application showing that information already running.

Good idea. Actually, I think I'm going to add this feature today.

> - The KCM would be as easy as: "I want progresses in the same
> window/whatever, or I want progresses on separate windows", with other
> fancy settings like: "remove finished jobs or move them to a "finished"
> list).
>
> - The biggest issue I can find here is what happens if you remove the
> plasmoid while it is the responsible of showing this information (while on
> "show all progresses in the same window").

Hmm, currently the correct tracker is only chosen when a new job get's 
registered. So in this case new jobs should get shown in the kuiserver 
application, but if there are already existing running jobs... well, that part 
might be tricky. I'm not sure how to avoid problems here.

>     - If it was already showing some information on progress, I think there
> is not too much to do with that... we can think about it later though.

agreed, I don't know if it's even really worth putting a lot of effort in 
handling this corner case gracefully.

>     - New started jobs should have no problems on starting the kuiserver
> app.
>
> Now, another issue I think we have to face is: imagine I am a user which
> selected "I want progresses in separate windows". If I add the kuiserver
> plasmoid, should it show a warning message: hey you need to go to this KCM
> and configure this as "same window", or should it just listen for jobs ?

> I would say the former. If you choose the latter, we would really be in
> some trouble with the dynamic tracker, which would be becoming pretty
> complex itself.

Well, as I said earlier this mail, I think we should always use kuiserver if 
it is available. So the KCM option would become a way to specify how to fall 
back if it isn't: to force kuiserver or to fall back to dialogs. And the 
dynamic tracker wouldn't become much more complex then it is: currently it 
does just that: falling back to widgetjobtracker if kuiserver isn't available. 
The only thing that would have to change is that we would still use the 
kuiserver tracker if the kuiserver isn't available, in case the KCM option is 
set that way. In which case the kuiserver tracker would start the kuiserver 
app. And it would spare the user a trip to the appropriate KCM. So I think the 
latter would be preferable.

Regards,
Rob Scheepmaker