thoughts on the systray

[Aaron J. Seigo]

On Monday 14 February 2005 10:06, Havoc Pennington wrote:
> > 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

if you mean a "notification system" in the sense of what we have in KNotify, 
no. if you mean a "notification system" in the sense that the application 
wanting to appear in the system tray and the system tray itself (which may be 
a non-gui representation for e.g. accessibility) communicate via IPC, yes. 

> 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.)

for applets, yes, i think we agree on the concept that cross desktop applets 
are important. how that will happen is the big question.

> 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).

it's that last part that gives me chills. the system tray spec sucks and i 
don't want to spend the next 3-5 years maintaining similar suckage for panel 
applets. if we open the doorway to XEMBED applets as a x-platform standard 
for KDE4, it won't be removable for a long time. this is a non-trivial 
decision, and i would far prefer something that allows me to make kicker more 
than a lobotomized gray rectangle. i understand the needs of applet writers, 
but please consider the needs of panel writers and the users who rely on 
those panels.

> 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.

the GNOME XEMBED implementation allows me to take a popupmenu that lives in 
the applet's process and manipulate it and then show it in the host panel's 
process? this is the trivial example i keep using because: a) it's trivial 
and i haven't seen it able to be done yet, and b) it's a real world example 
used by kicker.

> I agree with you that some kind of script approach (like Apple
> Dashboard) would be very interesting.

yes. i'll start looking into this and keep you abrest of that research. it 
won't start until after KDE 3.4 is out and i start working on the next 
iteration of kicker.

> Can we keep conceptually separate the various discussions though:
>  - applets

check

>  - "some kind of notification system designed top-down"

i don't think this is in-scope here. in KDE notifications are much more than 
what we're discussing here and i think that makes sense. 

i keep trying to describe a system tray that works over IPC and you and Owen 
keep coming back at it with "notification system". i hope this is just a 
communication error where we are using different words for the same thing.

for me and those whom i support with that code, the system tray is not just a 
notification system. at least not on our platform. while it is not the place 
to park desktop-neutral applets and minimized applications, the system tray 
is more than simply a notification system. this can (and will) be 
accomplished in a sane manner without functionally eviscerating it. more like 
performing an apendectomy, really ;)

>  - support Windows-style tray icons

check

>  - how to implement vs. what the design specs are

sometimes these two things have effects on each other. as much as possible 
i'll keep them separate, but where implementation and design interact i think 
it's important to acknowledge those interactions. =)

> 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.

agreed. if you read the rest of this thread on kde-core-devel i think you'll 
see i've thought a fair amount about this and have some half-decently 
structured thoughts on this.

-- 
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/20050214/bf9a24cb/attachment.sig>