Thoughts on uiserver
Ricard Marxer Piñón
rmarxer at iua.upf.edu
Tue Jan 16 12:36:07 GMT 2007
Rafael Fernández López wrote:
> Hi Ricard,
> 2007/1/15, Ricard Marxer Piñón <rmarxer at iua.upf.edu>:
>> 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
> Well, that's not my decision :P. We have planned maybe moving it to
> plasma, but I think the server itself should be on kio (kdelibs).
>> - 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
> Here there's something similar. All jobs on KDE (not on KDE4, but on
> KDE history) are done with a KIO::file_copy(...) and so on. They will
> notice the uiserver automatically if necessary.
> There's another extra life on uiserver, you can create "virtual jobs",
> for example when your program is computing some big amount of data,
> show a progress that isn't really a KJob in any case.
>> - 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.
> Well, that's not true. You can't pause a going on burning cd/dvd. You
> maybe wont like to pause some jobs. I think having some actions
> predefined is bad in general. We should let jobs decide what they want
> and what they dont want to do.
>> - all jobs should have a common way to "ask for user input" and another
>> way to "wait for user input".
> Hmm, probably you're right. We should wait to see the needs of the
> jobs on the uiserver, and see how far they get.
>> longterm thoughts:
>> - 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
> Have to think more about that. KGet does that right now. I think I can
> implement this, but that will be later (as you say longterm) ;)
>> I'm not sure if this is the place or the moment to post this, correct me
>> if I'm wrong, please.
> I really think never is late and never is so early. It is good to have
> ideas from other people, it always helps myself to know what people
> Bye and thanks,
> Rafael Fernández López.
Maybe I didn't explain myself well. Second attempt.
I see this in a more general way, and I'm more trying to address the
issue of general jobs (what you refer to as "virtual jobs").
I think a new protocol and a KDE implementation of such protocol could
replace the current KIO:Jobs (or maybe complement them).
The idea is that any application must be capable of publish a job (e.g.
"when your program is computing some big amount of data") he is doing
and an interface for controlling this job remotely (e.g. from a
centralized application or applet). In order to do so a simple protocol
is designed over DBUS, and in order to make use of this protocol simple
for KDE application developers a client lib is written in kdebase. This
library would make it easy to create a job and publish it's interface
and signaling (this is what your KJob class). And the KIO processes
would just have to create KJobs instead of KIO:Jobs (there has been a
discussion about this and I agree with the conclusions).
I know that inventing a protocol from scratch is a lot of work, but for
KDE developers this protocol can be more or less invisible (and then
flexible and changeable), while the KJob class shouldn't change so much.
I think you did quite a good job with KJob (nice phrase). But I have
some worries if it could fit well with an evolution of the protocol
behind, and since the interface is still under development it's a good
moment to post my worries.
I have been thinking a little bit about the protocol behind. And this
is how I see it (could KJobs cope with it? if not, maybe the protocol is
THE CLIENT (KJob):
- when a Job is created a dbus signal is sent and one of the arguments
is the dbus interfaces of this Job.
+ I chose a signal because the fact of publishing a Job and exposing
its interface is a many to many communication. I believe its a many to
many communication because there are several different ways of showing
and controlling Jobs (from a UI point of view). One could be the window
with progress bars (a Job Progressbar applet) you should and another one
could be a time line where you could schedule jobs (imagine being able
to have a movie playing, published as a job, and in the Job Timeline
applet add a shutdown action when the movie finishes, or having a file
downloading and at the end schedule a burn to CD job). Well the fact is
that both applets should be able to run independently at the same time,
and listening to these signals.
- the dbus interfaces of this Job can be created using KJob (exposing
slots thanks to Qt love) or some that already exist (such as
PauseableJob (some Jobs, like CDROM burning will not have this
interface), StoppableJob, CancelabeJob).
+ When I mentioned in my last email that all Jobs could be
pauseable(), I meant that being pauseable or not is a property belonging
to all jobs (CDROM burning being not pauseable() and some file downloads
yes). Having this and some few other properties common to all jobs
allows for some really nice interaction by the user (like pausing all
pauseable jobs, or having by default a stop all stoppable jobs on
computer shutdown and a question whether to cancel or not non stoppable
+ But I understand your desire of having actions general, that's why
I propose doing it by dbus interfaces, in this way it's up to the
application developpers to create their own or use default or predefined
ones, and to the Job applet (server) developers to created special
delegates for these dbus interfaces.
- when a Job changes state (pauses, stops, cancels, progresses,
estimated times, changes its dbus interfaces, asking for user input,
waiting for user input,...) a signal is sent.
THE SERVER (Observer or the Plasma applet):
- it listens to signals of created Jobs, Job state changes and it
creates it's proxy objects and it's views and delegates on it's own way
(a progress bar, a timeline,...)
Well, I hope with this explanation I made myself a bit more clear. I
don't really know the inner workings of how it is right now, but I think
it's not far from this. I think the fact of having a dbus protocol
independent of the client and servers implementation makes it easier to
extend to non-KDE apps and make it more flexible for the long run.
Some questions I don't know how to answer related this design:
- Are dbus signals much less performant than the client-server direct
communication? (for example is much better to have only one Observer
server with a JobServer)
- Is it possible to define dbus interfaces without any applications
running? (for example the default interfaces I mentioned like
- Is it possible to define inheritences on dbus interfaces? (for example
a FileTransferJob could inherit from PauseableJob, StoppableJob,...)
- Can the applications that are launched after a dbus signal get that
signal in someway? (for example if a Job has been created before the
server has started)
After all this talk, I must say, that I'm in no position to ask for
things, since I'm not really helping with the development. So this is
more of a brainstorm and ideas sharing than anything else. When I get
the energy I'll set up the KDE development environment setup and help
you with your work.
Thanks for reading,
PS: Have you thought of calling the server Jobserver (or would it sound
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