Thoughts on uiserver

Ricard Marxer Piñón rmarxer at
Mon Jan 15 16:17:22 GMT 2007

I have followed a bit the later development of the uiserver and have a 
few questions/thoughts:

- should the uiserver still belong to KIO now that it handles Jobs other 
than input/output operations? other reasons apart from the history of it?

- the uiserver clients (the apps that want to publish their jobs and job 
progresses) should publish the actions available for the given jobs 
using DBUS.  a job would the be a DBUS object implementing one or 
several DBUS interfaces, that can be predefined or defined on runtime.  
I think this is how Mathusalem does it and it allows for more 

- all jobs should be pauseable, cancelable and/or stoppable.  These are 
common actions to all jobs and might be handled differently than other 
more specific actions.  This can be implemented as a base DBUS interface 
for every job:
    + pauseable() means the job can be paused and resumed as long as the 
application that owns it is still running.
    + cancelable() means the job can be cancelled.
    + stoppable() means the job can be stopped and resumed even if the 
application that owns it is not running anymore.

- all jobs should have a common way to "ask for user input" and another 
way to "wait for user input".

longterm thoughts:

- a client should be able to publish a job in a STOP (or NOT_STARTED) 
state, and wait or ask the user to start it.  (use case: from konqueror 
I can say to download a file and burn it to a CD, this would create two 
jobs and put them one after the other, the second being on a NOT_STARTED 

- being able to publish trees of jobs (jobs waiting for other jobs to 
stop before they start or several jobs starting at the same time). (use 
case:  when a user selects several files to be copied, he wants to make 
the files to be copied in parallel or in series once the job has started.)

I'm not sure if this is the place or the moment to post this, correct me 
if I'm wrong, please.


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the kde-core-devel mailing list