-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 29 October 2003 05:04, Lubos Lunak wrote: > > > 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. > > They maybe seem to work, but they don't really. I'm quite sure you'd find > a couple of examples in our bugs database, or just search http:// > mail.gnome.org/archives/desktop-devel-list/2003-March/thread.html for some > examples (the long thread called Notification Area guidelines). we were talking about XP's tray management, not ours or GNOMEs =) as for the thread on the GNOME list, that's the sort of stuff we would be able to do with a DCOP-driven systray and at least part of the reason i'm suggesting that route. > > > 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. > > Even you yourself are confused by the way systray works. Systray is > currently used for several different things - this proposal is supposed to > be only for the case when the app is trayed just to save space > (kscd,ksirc). read what i said again: because the systray doesn't work only as a place for icons that also have windows, we'd now have two places that these things appear. this is bad design and would make for a rather stupid interface. i understood it completely, i simply wouldn't be comfortable with the idea. > > 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. > > Of course not. It would be the systray/taskbar/WM who would do it. that doesn't decrease the hack value of it, though. it basically conflates the meaning of sticky hidden windows with "traditional" systray behaviour. overloading meanings in the UI is a path towards insanity, for even when they are hidden from the average user they are not hidden from the programmer writing the code or the advanced user... there are some things in kicker which are "hidden" from the user, but which as a developer i simply detest. systray's use of QXembed, for example ;-) of course, this eventually bleeds out to the end user as the illusion isn't always perfect because it's, well, a hack. > > 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. > > It would be much easier to do if we had cleared guidelines for this. > http:// > developer.kde.org/documentation/standards/kde/style/basics/systray.html is > apparently not enough, because unlike the rest of KDE, the systray isn't managed by policy set in the libraries but relying on each app author to do the right thing. even when we extend the system tray guidelines, it'll remain an issue. the systray ought to manage itself. > if we do have the broken cases (my personal > favourite is Klipper's "do you really want to start me next time?"). you mean when you quit Klipper by it's icon? yeah, this is one of those unfortunate and hard to avoid situations due to the interface. > Your > suggestion to have always-visible/only-when-active-visible and allow the > user to hide some of the systray icons can improve the situation. But maybe > we can simply improve the whole concept, instead of bandaging it. the two sentences above are orthogonal to each other =) even when we improve the means of communication, we'll still end up with a list of applications that are requesting use of the system notification area / systray. that facility will need to decide when, where and how to facilitate the UI of this. as for improving rather than bandaging, i'd really like to see us drop QXembed altogether save for backwards compatibility and move to a 100% DCOP-driven system. at this point we can make the UI look like pretty much whatever we want, even have multiple types of interfaces as options if we wanted. which brings us to the question of what the DCOP interface would look like. i don't have time to sit down and really design that until post-3.2, but am looking forward to that process =) - -- 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/n/331rcusafx20MRAthvAKCVQ1nTpaywXCt53iAHwXDtCdeODwCgp3Jz PY9QU196ANFjs1OAvJbakRU= =LNwZ -----END PGP SIGNATURE----- _______________________________________________ kde-usability mailing list kde-usability@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-usability