[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Proposal: kde guide systray update
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2003-02-04 5:13:32
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 03 February 2003 06:08, Datschge@gmx.net wrote:
> > how would the animation referred to be provided and look like? 
>  
> The best choice is the already existing windows animation/genie effect 
> you get when minimizing a window to the taskbar. The code for this 
> exist already and users are familiar with its purpose. 
 
that makes sense... this shouldn't happen if the window is simply minimized 
though (which is what i though when i read "All ways of showing/hiding the 
main interface"), but only when the last window is closed. I'm not sure, 
programmatically, how this would be easiest to accomplish. I don't want 
systray support to become a burdone for app developers.... 

i'm also not familiar with the code that does the minimize/maximize animation 
(i'm guessing that's in KWin's client code?), but i would guess that there 
would need to be some work done to:

 o know where the systray is
 o be able to tell the WM to animate tot he systray rather than the taskbar

since this is done for the taskbar, i can only assume that it is possible to 
be done for the systray, but this implementation detail should be looked 
into...

> It absolutely makes no sense to use the systray if there's a window
> already. If there's a window then it appears in the taskbar, so use
> the taskbar to deliver simple notifications through changing/blinking
> icons.

systray icons are there not just to show status information but to provide 
access to functionality (which allows apps with no real "main window" to 
operate primarily via the system tray).

kmail and kscd are both very good examples of this. kscd offers a way to 
play/pause/next/prev etc... the CD that is playing. this is very handy as it 
means you don't need the window around all the time. in the case of KMail, it 
offers a way to both see how many new msgs are in a folder and jump quickly 
to that folder.

it makes no sense for either app to show a systray icon w/out the app (since 
the systray icons basically require the entrie app's functionality) and would 
incur extra burdon on the developers of those apps to provide such an app.

these are examplse of apps making *use* of the systray, we shouldn't suddenly 
outlaw this style of usage in the name of a detailed guideline. rather, i 
think the guideline should recognize both sorts of systray usages and make 
clear provisions for both.

consensus seems to be that your draft covers the case of the "GUI daemon" type 
app very well. i'd like to see it expanded to include non-"GUI daemon" apps.

> Btw Aaron, I was looking for related guidelines for Gnome and didn't
> find any (only some notes regarding accessibility using a keyboard).
> Should I introduce my draft to the open-hci mailing list for discussion
> as well?

that would be great...

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

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+P0v91rcusafx20MRArNzAKCIubthfK/5gPGnxzbSTjhRxVcnzACeMK3J
itpxwrt8YEx5ZE55OmSfaXs=
=3K4V
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]