SoK -- KUiServer and Plasma DataEngine changes need approval...

Shaun Reich predator106 at
Sat Jul 4 20:32:52 BST 2009

Hello, I sent this message to both kde-core and plasma  --devel
mailing lists, as it applies to both of them, moreso the former. Some
of you may know, I have been working on an SoK project to show the job
(transfer) progress within icons.

There are different levels to this, two of them involved making
KUiServer become the new receiver for KJob's. KUiServer then kind of
is seen as a server for those, in turn, any "client" that requires
this information, can merely call the method "registerService"
(address, objectPath), to the "org.kde.kuiserver" D-Bus address. This
tells KUiServer to now send job information to aforementioned client.
When this client first sends that message, KUiServer will send
"requestView" calls for each job that it currently has running.

The structure is identical, the client just has to abide by the
standards of "org.kde.JobView.xml" (and "org.kde.JobViewServer.xml",
which I think contains "requestView"). The "requestView" method call,
returns an objectPath, and KUiServer will have each of it's jobs
forward the *exact* method calls that they themselves receive.

So basically, the client is essentially transparent to it other than
the fact that it has to complete the initial registration. After this
is done, existing jobs, new jobs, and job updates will be given to
that client..

KUiServer currently works perfectly (as far as I can tell), with
Plasma (after making and installing both KUiServer, and the Plasma
DataEngine). The jobs notifications display like nothing has changed.
I also made the UI of KUiServer only construct itself if no clients
are connected, and delete itself when one is. This makes it very very
light. It currently starts itself via the D-Bus auto start service
magic. In other words, it only starts itself when a request is made to
it (by a client). I am not so certain about the case when no clients
made a request, but Jobs need to have requests. I'm not sure if I
should cover that case or not.

I would like to get both of the below folders merged back into trunk,
now that it is cracked open (yay!), but I need to get them reviewed

Ideally, to the user this process should be completely transparent
(this initial merge at least).

I have tested it (naturally) quite a bit, having to transfer a bunch
of data over the LAN anyways, and have found no faults with it so far.
But of course, there could be something I am missing, especially after
playing with it for so long, perhaps my mind just wants it to work
seamlessly ;-)

If you want to test it out and/or look at the code, effected files are
located at '/branches/work/sok-progress-in-icons/runtime/kuiserver/' &
(only the kuiserverengine class had to be modified in this folder).

Let me know what your thoughts, opinions, etc. are, and what any
mistakes I have made ;)

Just a note: KUiServer's self-made Ui is currently...sub par, I
suppose, but it should work fine (it did since I last tested it). I
will get back to working on this section of it (and other sections),
after I "finish" the drawing of the job progress, within icons, etc.,
since I personally deem the Ui as a lesser importance
currently--whilst there are bigger fish to be had :P

Another note... I am now "considered" the "maintainer" of KUiServer,
as the former one, 'ereslibre', 'Rafael Fernandez Lopez' is his name
if I recall correctly (apologies if I spelled that incorrectly/got it
wrong altogether). He is currently low on time, and upon asking,
passed it to me. Besides, since I cleaned up it's entirety, to
separate classes into their own files, make it easier to read and what
not, etc. (as opposed to friends---which bug me beyond disbelief), it
is probably best/easiest that I maintain it now, since it is no longer
going to remain dusty and dormant...and from all of the changes that I
have made.

I think that's everything...

Riverenter Vestri,
Shaun Reich

More information about the kde-core-devel mailing list