JobViewServer patches

[Rafael Fernández López]

Hi all,

Despite the crazy merge of patches I have on kdelibs and kdebase, I think 
attached patches are clean and can build (I haven't tried them though), 
because I have more unrelated changes. I think I didn't forget anything.

There is still work to do, but the basics are working. I was impressed 
qdbusviewer has a bug when calling methods and doesn't call them correctly, 
for instance, it will call requestView OK, but when you call setPercent for a 
certain job, it will ignore you. It won't happen with qdbus. qdbus works 
perfectly.

You can also try it with kjobtrackertest (in kdeui/jobs).

Some comments:

- Of course there is still lots of work to do on the kuiserver itself, there 
are methods that are not implemented yet. (descriptions, for example).

- kdecore at the moment does not provide what we promised for the spec. I 
mean, KJob on its Unit enum hasn't got Contacts and some other we talked 
about. I guess we could leave our implementation with bytes, files and dirs 
for now.

- It is very important to say explicitly that jobs will be of the form 
JobView_ID (where ID is an unsigned integer). Each time a job calls to the 
requestView method from the server, a new ID is assigned to that job, and a 
new job adaptor is created and registered into D-Bus with the ID that the 
kuiserver assigned to that job.

I have been thinking on our solutions for KIO, and I just started to worry, 
because KAbstractWidgetTracker & friends are very close to KDE (they always 
take KJob*...). So, I think I also have to implement a "show in separate 
windows" feature for the kuiserver.

It makes sense to me that Gnome's solution as kuiserver will read the same 
configuration file, where the user specifies if he/she wants separated 
windows progress or not. There are some possibilities:

        Separate Windows  Separate Windows  Unified Window  Unified Window
            KDE job           Gnome job        KDE job        Gnome job

KDE    kwidgetjobtracker*     kuiserver       kuiserver       kuiserver

Gnome      mathusalem           GIO ?*        mathusalem      mathusalem

On those with (*) I wanted to point out we can bypass D-Bus, and thus, be 
faster. Is what we do at the moment when the progress windows come up. They 
are not going through kuiserver.

I find a serious problem when talking on cross-desktop at this point. If we 
are using Gnome desktop, and a KDE job comes up, and our preference is to 
show progress in separate windows, then kwidgetjobtracker would come up, 
instead of mathusalem in separate windows, that is what we would like to, for 
the GUI being consistent with the rest of the desktop. There we should make 
some difference, a question that I don't know if is possible to do, something 
like "is a KDE environment running?".

Comments and ideas are welcome.


Bye,
Rafael Fernández López

GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs-kuiserver.diff.bz2
Type: application/x-bzip2
Size: 4273 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080223/e5e2d9db/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdebase-kuiserver.diff.bz2
Type: application/x-bzip2
Size: 7722 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080223/e5e2d9db/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080223/e5e2d9db/attachment.sig>