thoughts on the systray

[Aaron J. Seigo]

i'm CC'ing kde-core-devel on this, i hope you don't mind. there isn't anything 
inflamatory or personal in your email, so i don't see why it would be a 
problem.

(for k-c-d readers this is a discussion about the upcoming changes to applets 
and the system tray that will affect kicker in KDE 4. see 
http://aseigo.bddf.ca/?pID=1092 for the brief write up i did that Own is 
responding to)

On Saturday 12 February 2005 05:59, Owen Taylor wrote:
>   1. Come up with a new, good notification API (probably using DBUS)
>      that meets the requirements of a KDE UI design and a GNOME UI
>      design.

it's more than notification. if we look at what people actually use the system 
tray for, notification is one of the things its used for. if we say "only 
notification, every one else go elsewhere" we will end up with the same 
problems, only not in the system tray. instead, we'll have a bunch of applets 
on the panel taking up even more space and committing the exact same abuses. 
not a brilliant solution.

we must, IMHO, allow for more than notification in the system tray, while 
setting out some basic guidelines that eliminate things like "using the 
system tray as a means to keep your app running and accessible even with no 
windows showing".

>   2. Do something to enable Windows tray icon compatibility for things
>      like Wine.

good idea.

>   3. Write a spec for arbitrary GUI panel applets that uses XEMBED
>      but is better thought out than the systray ... allowing for
>      size notification, menus, and activation. (Add an applet...)

i am vehemently against the use of XEMBED in kicker. i just got through 
removing XEMBED usage in kicker, except the systray of course, due to the 
number and scope of problems it created. 

i hope you understand that it's more than a little frustrating to be the one 
who is actually going to be implementing this stuff and who is saying, 
"please don't hobble kicker by making me use XEMBED" only to be basically 
ignored by those creating cute standards but who aren't going to be writing 
the code or maintaining the mess afterwards.

> For 3, I think using XEMBED and out-of-process is a real gain.
>
>   - Cross-desktop applets are useful ...

agreed. let's find a better way to do them than via an out-of-process, 
X11-specific mechanism. let's round up all the applets that we'd like to see 
cross-desktop and see if there are commonalities amongst them that would 
allow us to create a _scriptable_ applet. loading Python scripts into kicker 
as an applet, for instance, is fairly trivial. it was actually done a couple 
years ago as a proof of concept, even. the question would be: what set of 
Python interfaces would be required to give applet writers enough of a tool 
set to do what they need to?

and hey! suddenly we'd open up applet writing to scripters. i don't know about 
your experience with vendors and writing these sorts of tools, but they seem 
to prefer script based solutions over writing in C/C++. YAST, Mandrake 
Control Center and many others spring to mind.

and this would also work in environments w/out X11!

XEMBED is a tempting solution because we know it well, because it's near at 
hand. but it's a bad solution (see below for specifics); we just need to 
apply some creativity and maybe a little extra groundwork to get something 
good.

>   - Ability to have an applet in the same address space of the
>     app.

theoretically interesting, but history has shown this to be unnecessary. this 
is what we have IPC for, and DCOP has shown that it's easy enough to use that 
there is little benefit here.

in fact, there are downsides to this, namely that the applications start 
popping up applets on their own and users have to around cleaning up after 
them. people tend to customize their panels; it's not a place for apps to be 
messing with on their own.

that said, having applets that come and go with an application sounds like a 
bit of a usability mess, since now the applet (which is seen as a unique, 
distinct entity from the application itself by a user) is now tied to the 
app. it's bad enough that we have icons coming and going in the system tray, 
moving this to general panel entries is worse.

applets in the process of other apps also means that those other apps MUST 
remain responsive at all times. having parts of the panel GUI freeze up is 
not an option. in other words, the panel would suddenly rely on all sorts of 
3rd party apps to "get it right" (which, looking at history, many/some won't) 
to provide a proper user experience.

>   - Stability

kicker deals with this just fine w/out xembed. in fact, it deals with it 
better _now_ than it did when xembed was used. morover, even WITH xembed, it 
was possible to crash kicker depending on what was happening at the moment 
the xembed'd widget went bye-bye on us.

> The downside of XEMBED and out-of-process is that you have to
> write X specifications and do IPC rather than just writing a
> widget class for people to subclass.

well, that's not true either. in KDE we have a subclass that does all the 
XEMBED stuff for an ap using the system tray. the same could be done with an 
in-process applet. this isn't a downside of XEMBED. the fact that it's 
X-specific is.

XEMBED gave us problems with drag and drop into applets, it gave us problems 
with doing things like requesting the applets to give kicker an 
applet-specific menu to show in a standard location (the applet handle menu), 
it increased overhead as you have N processes with N event loops going on, 
etc...

kicker in KDE 4 is not going to be the placid little grey square it currently 
is. in KDE4, kicker will need to be able to ask an applet what sort of 
information it's displaying, give it "stage directions" as to how to present 
itself and likely other interesting UI enhancement.

well, unless i'm forced to use XEMBED, in which case forget about doing 
anything truly interesting with kicker. XEMBED makes things slightly easier 
for certain types of application developers, primarily *vendors*. the 
collateral costs are born partly by me and other panel developers, but mostly 
by our *users*. this is not an acceptable trade off in my mind. =( let's find 
something that works for everyone.

> of your writeup. I dont't know if I fully understand the scope
> of what you consider appropriate uses of the systray, but it's
> clearly not about arbitrary unconstrained user interface.
> If you allowed in-process embedding of arbitrary widgets, you'd
> have most of the same problems that you discussed.

i fear you didn't understand what i wrote then. =)

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.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050213/a5d94871/attachment.sig>