Thoughts on uiserver
Ricard Marxer Piñón
rmarxer at iua.upf.edu
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
interoperability.
- 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
state).
- 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.
ricard
--
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