JobViewServer specification proposal

[Aaron J. Seigo]

On Thursday 24 April 2008, Florent Mertens wrote:
> 1. Client app don't show a progress window/bar, and provide it only
> via the JobView server
> 2. Client app still show a progress window/bar, and provide it also
> via the JobView server

isn't this an implementation detail for the application to take care of? many 
apps will be just fine with 1, but for those apps where 2 is appropriate they 
can simply hook into the appropriate local signals, no?

for the user, however, having these things aggregated in one place with a 
consistent look and feel is the most useful thing.

> If we go for 2, we should add to the API some kind of
> iconify/deiconify signal to be able to iconify
> the application. A lot of long time running tasks provide a tray icon
> nowadays. We should not clutter
> user's window list, while uncluttering their system tray.

tray icons are really, really horrible. for long running tasks such as these 
i'd prefer to leave it up to the job visualization to decide how to deal with 
that and get away from systrays full of 
potentially-needed-but-mostly-dormant-icons that are there just to provide UI 
persistence.

> If we go for 2, not sure that a stop/start/resume is required
> (duplicate functionnality).

while perhaps not strictly necessary, it would bring a nice consistency while 
agregating common functionality in one place. it also alleviates the 
application itself from having to supply this.

> If we go for a mix of both, this might be confusing for users.

confusing as in causing the user to say "i don't know what's going on!"? give 
people a bit of credit here.

it can lead to more clutter than strictly necessary, which is why i think an 
app providing it's own parallel visualization for progress of a long running 
job should be the exception rather than the rule and that such in-application 
visualizations should be kept minimal (e.g. a progress bar somewhere in the 
app's main window rather than a whole other top level dialog)

> My own preference is 2, but i'm a bit biased because of the nature of
> my application.

i hope that instances of 2 are rare. while it may make the application 
developer feel more proud about their application's importance and 
usefulness, i doubt that will often translate into user satisfaction.

when it comes to communicating things like long running jobs to the user, that 
is something that the desktop workspace itself is best equipped to provide 
services for: it can do so in a way that works with that environment's UI 
concepts, that blends with the look and feel and create a consistency between 
all apps regardless of how those apps themselves were implemented. moving 
away from "every app is an island" is pretty important to getting an 
evironment that feels like it works well together, imho.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080424/12561417/attachment.pgp