JobViewServer specification proposal

[A. Walton]

On Tue, Apr 1, 2008 at 2:50 PM, Rafael Fernández López
<ereslibre at kde.org> wrote:
> Hi all,
>
>  I would like to start to work on a specification proposal for Freedesktop that
>  we have named JobViewServer/JobView.
>
>  The goal of this specification is being able of implementing this idea
>  http://dot.kde.org/1169588301.
>
>  Regarding this issue there are currently two main applications on Gnome and
>  KDE (I don't know if exists something similar on other desktops), called
>  Mathusalem [1] and kuiserver [2] respectively.
>
>  Long time ago I talked with the mathusalem developer, and I was very
>  interested in sharing the same D-Bus interface so we could do very
>  interesting things, but from what I recalled he wanted to rewrite
>  Mathusalem's interface.
>
>  Afterwards Kevin Ottens proposed to rework our kuiserver API, making it
>  simpler and cross-desktop. Of course, I accepted and implemented it on KDE.
>  Our decision of first designing the specification and later implementing it
>  was just for testing it in the practice, and find out that it worked just
>  fine.
>
>  Now we have the implementation finished and I wonder if some of you want to
>  help out with the review and suggesting ideas. We would like this
>  specification or similar to become a cross-desktop standard.
>
>  Benefits:
>
>  1) One could select to see I/O or other consuming time operations in a single
>  or multiple windows.
>
>  2) What is really amazing: One could use Konqueror on Gnome desktop, for
>  example, and when going to download a file, the progress dialog of Gnome
>  would show up [if multiple windows enabled, for instance], instead of the KDE
>  (kio) one.
>
>  This opens a door for cross-desktop being a reality, and I really think we
>  shouldn't miss such an oportunity.
>
>  Since this is an introduction and not an spec proposal at the moment, I would
>  like to know what do you think.
>
>  If everything goes fine, and this seems to interest the rest of the desktops,
>  I can explain the spec, let's say for 04 April.
>
>  [1] http://live.gnome.org/Mathusalem
>  [2] http://websvn.kde.org/trunk/KDE/kdebase/runtime/kuiserver/

Maybe it's just me, but I've always found Mathusalem to be a bit
obtuse, as it'd require writing a lot of special-case code for
something that's little more than a very long running notification.
And it just so happens FD.O already has a specification for
notifications [1], a daemon and client implementation, and it's well
adopted code in the GNOME community (I can't speak for the KDE side of
things).

What really needs to happen, IMO, is an expansion of this existing
standard and code to allow it to be flexible enough to be used with
very long running applications. Not a lot needs to change to make this
happen either: to make the notification not expire until we want it
to, set the expiration timeout to 0, a new hint needs to be added
"progress", which indicates how far along a current job has progressed
(obviously), the "categories" should really have some more generic
"long running task" category, such as "Job", and the addition of a few
methods to make it easier for application developers to update
existing notifications such as GetNotification and ListNotifications.

So then applications just need to be able to hold on to, or get hold
of, the notification-related information and send notifications to
update the current one when necessary. The standard facilitates this
with the "Replaces ID", which I've found to be sufficient in the work
towards this that I've done. With some further work, the existing
libnotify client could handle these details.

Of course, the current implementation of the notification-daemon is
near useless; you can't hide/reject notifications from parties you're
not interested in, you can't get a history of notifications, and
there's no way for applications to get a list of other open
notifications nor a specific notification (so if your application's
hoping for the daemon to hold on to this information for you, you're
out of luck; I was very surprised at the missing GetNotification and
ListNotifications methods, but that's just me). It's also missing an
applet/bin/"widget" that contains the open notifications that are
hidden from view (the user "dismissed" it, but it should persist until
the application says otherwise, the application that fired the
notification closes, or until it expires, I would think). And of
course there's no Qt/KDE theme for it as far as I can tell, which is a
shame. These are all specific defects in the existing code and
standard that are barriers to entry which are very easily overcome,
it's just a matter of sitting down and doing the work.

Perhaps my thoughts are just bending an existing standard way outside
of its usefulness and I'm totally wrong, but I'd suggest taking a good
read of this standard and seeing if you can really make it work. I
started work on this last year, but I never followed through with it
like I should have. This would be a good opportunity for reviving this
standard and the code. I wouldn't mind working with you on this if
you're interested in some help.

-A.Walton

[1] http://www.galago-project.org/specs/notification/0.9/index.html

>  Bye and thank you,
>  Rafael Fernández López
>
>  GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070
>
> _______________________________________________
>  xdg mailing list
>  xdg at lists.freedesktop.org
>  http://lists.freedesktop.org/mailman/listinfo/xdg
>
>