From kde-core-devel Mon Feb 14 17:06:00 2005 From: Havoc Pennington Date: Mon, 14 Feb 2005 17:06:00 +0000 To: kde-core-devel Subject: Re: thoughts on the systray Message-Id: <1108400760.3621.27.camel () localhost ! localdomain> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110840073518390 On Sun, 2005-02-13 at 15:58 -0700, Aaron J. Seigo wrote: > the idea i'd like to see for the system is thus: > > o a DBUS bus that applications can publish "i have a system tray entry, here > are the details of it". the application would update this information as > state changed. think about autohiding icons, for instance, and the need to > know the current state of an application (idle, important stuff happening, > etc). > > o host apps (e.g. the systray applet in kicker) would consume this data to > present an interface. the interface would be 100% under the control of the > host app, including what to do when the user, for instance, right clicks on > an entry versus left clicks on an entry. > > the application with a systray entry would only publish data, (and receive > event notifications, for instance "the user wants to see a context menu for > this entry") and not have anything to do with the actual presentation or > management of the GUI. this immediately puts some limits on the system tray, > allows the host app to sanely and powerfully manage the information in its > display and separates the publish/display actions. > This is a different problem space than what we discussed at XDevConf. You're talking about some form of notification system here, our discussion of that was "we need to know what the interaction designers want it to do, then we can discuss it after that" and we moved on. For applets the people in the room (Owen, Lubos, clee, Lars Knoll, myself, probably I'm forgetting someone) felt we had a better idea what the desired design would be like. (Maybe we didn't, though it sounds like you're disagreeing on implementation, not design.) What we discussed was to have both in-process applets (which would be desktop- specific) and out-of-process (which would be sort of like the system tray spec). As an aside, I think most of your XEMBED problems were probably due to a bad implementation of it; I don't think the Qt XEMBED widget was ever really finished? I could be wrong. But anyhow, that spec works fine for GNOME applets and such. I agree with you that some kind of script approach (like Apple Dashboard) would be very interesting. Can we keep conceptually separate the various discussions though: - applets - "some kind of notification system designed top-down" - support Windows-style tray icons - how to implement vs. what the design specs are I feel that we have to continue to support the current tray icon spec, since *tons* of apps are using it; and given that, it may as well be the answer for "Windows-style tray icons"; for a new spec, we should start with a designed UI that makes more sense. Tray icons are a broken idea inherited from some ancient Windows version, MS itself keeps trying to get rid of them; we should just support them as a back compat thing and replace with some better-thought-out features. Havoc