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

List:       kde-usability
Subject:    Re: ksytray madness
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2003-10-27 18:36:18
[Download RAW message or body]

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

On Monday 27 October 2003 03:41, Mike Hearn wrote:
> Have you considered the possibility that the system tray is just a
> generally broken concept?
>
> It's used for the following things (in theory):
>
> * Notifying people of things
> * As a mini-ui for quick access to various features of the app,
> typically raising it on the current virtual desktop. Often tray icons are
> used as a desktop-portable form of panel applets, obviously this is not
> ideal.
> * To indicate that an app that otherwise would have no main window is
> running, allow it to be quit etc
>
> All these tasks are really separate, but are lumped together into the
> "tray" because that's what Windows has always done. Then you end up with
> nasty hacks like in XP.

"nasty hacks" that seem to work just fine for the majority of people who use 
it.

> a) Add a new EWMH hint which causes the window list/taskbar to shrink the
> window button to just an icon (and hide the border), then pack it to one
> end. Combined with the sticky flags that already exist, that allows you to
> have a window always accessible on any desktop - one of the primary
> things many apps use the system tray to do.

so...... create a system tray in the taskbar.

first, this is not how system tray icons work as they may not have an 
associated window at all. so while some icons would appear in the taskbar, 
others would then appear in the system tray, probably seemingly randomly to 
most users. either that or else there would be icons with no associated 
window in the taskbar. gah. that's one aspect of MacOS X i'd prefer to see 
KDE not reimplement.

second, this overloads the meaning of buttons in the taskbar and makes the two 
concepts (windows and "action mini-icons) linked so that to have one you have 
to have both and they must be right next to each other. sounds like a 
regression to me.

third, it means that each app would have to do the right dance: sticky the 
window when closed, say that it should be shrunk in the taskbar. this could 
be addressed by adding support for this to the various window classes, but it 
just feels hacky.

i'm not so hot on this idea of relocating the problem.

> b) Allow apps to embed new menu items into their window menu. We need this
> in the Wine project anyway. That would mean you could have the equivalent
> of the tray icon menu, but as part of the window menu. You've now replaced
> the "mini-ui" use case completely, but it's semantically cleaner: the
> window list is for managing windows, the system tray is not.

yes, i've already been mulling how to do this since it's a clear and obvious 
extension of the taskbar. at the same time, if all it only adds to the 
context menu of the taskbar button then we've hidden the interface completely 
from most people. i'd much prefer a "this button has a menu" indicator which 
when clicked on will pop up the action menu for that window.

the remaining issue is how to define and popup a menu from one process in 
another. of course, we face this with a DCOP-driven systray as well.

> c) Provide a poptart/toaster service. The tray as a means to notify the
> user of things is kind of flawed anyway, the icons are small, easy to
> miss, and so you have to resort to balloons and things to get your message
> across. The way MSN Messenger does it seems better to me - and besides, if
> there is a generic service to do it, you can choose whatever
> representation or ui you like.

we already have this: KNotify. together with passive popups it's rather 
effective and more apps are using it.

> I'd suggest that be done via DBUS, *not* 
> DCOP, as otherwise apps like Gaim that wish to be desktop neutral will
> just re-invent the wheel to avoid dragging in Qt/kdelibs etc...

DBUS is not production code and therefore not used by anyone. when/if DBUS is 
ready for prime time and when/if KDE adopts DBUS, there will likely be a DCOP 
bridge/translator and so it won't matter what this is implemented in. if it 
were done in DBUS today Gaim still wouldn't use it, and neither would any of 
the KDE apps. if this gets implemented after (if) KDE adopts DBUS, then it 
will likely be implemented in DBUS.

> d) For apps that are running but have no main window, for instance
> khotkeys, oooqs etc, the session manager might be a better place to deal
> with these apps. As it is, the user is being informed about an
> optimization (preloading OO) that should just be hidden, they don't need
> to know about it.

yes, some uses of systray icons are just broken and should be fixed. there are 
broken implementations using just about every desktop service available, in 
fact.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/nWWi1rcusafx20MRApEOAJ9YjvNjdCBZDDiR1GXRg7bDw6k1VACglHU0
QaQbOxt9FcAF/s4lsykefa4=
=fgtL
-----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]