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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
