kuiserver refactoring (again)

[Olivier Goffart]

Le Mon Feb 5 2007, Rafael Fernández López a écrit :

> I managed to get rid of the newAction dbus method on the kuiserver
> interface, so it can't be called through dbus. In addittion, a new
> parameter is added to newJob on the kuiserver, that is the capabilities of
> the job.

So that mean we can't have customs actions ?
(such as "show more info" or "speed up")

> There is an issue on KJob:
>
> If a KJob was started (well or another class that inherits it), and while
> in progress, the app crashes, the job will remain forever on the kuiserver.
> I've fixed it emitting the finished signal on the destructor. I think this
> is not as good as we may expect. And of course, I want to know what you
> think.

I have the same problem in KNotify.
It'll be cool if D-Bus could tell us when an application crash.

> I think I should remove the newJob method on the observer with no KJob
> parameter. If developers want to show a job, I think the better solution is
> to write a full-supported class that inherits kjob. What do you think ?

Yes, that method could be removed.

Maybe we can have a generic KJob to do that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070205/e6c7b1bd/attachment.sig>