[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-23 23:58:43
[Download RAW message or body]

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

On Thursday 23 October 2003 09:56, Fabrice Mous wrote:
> Don't no if this has been discussed here before. I checked out the archives

no, not here, but on bugs.kde.org there has been some... when i was looking at 
various systray issues a couple months back (still have a few more to address 
for 3.2.. must. find. time.) i rolled this exact problem around in my mind 
and on paper for the better part of a week... i even coded up a few 
possibilities with varying degrees of satisfaction, but eventually conceded 
that this requires extending the XDG system tray functional significantly. 
here are my thoughts:

systray widgets should have (at least) three possible states: active (meaning 
it represents an action in progress, e.g. a received email), inactive but 
interactive (meaning there's no action in progress, but it offers some sort 
of control interface, e.g. a media player's next/prev/stop/start menu), 
inactive and non-interactive..

Icons should be hideable. This should be done via a few methods:
	a) from the app the icon belongs to. the app should NOT have a "show systray 
icon sometimes" option, since many already have a "show systray icon" option 
and this would just lead to confusion. it also raises the spectre of syncing 
this option with the systray itself, which is asking for maintenance 
headaches. instead, the app should mark the icon as hideable when there are 
no pending actions or application interaction possibilities via the icon at 
that time. conversley, the app can mark the icon as being in an active state.
	b) from the systray, the user should be able to say "don't show this icon". 
perhaps a simple RMB/handle menu, ala the mixer applet. these user 
preferences would over ride the program supplied states.
	c) the systray itself should hide inactive non-interactive icons

Sytray autoexpansion: the systray should expand to take up more panel space 
either on mouse over or by some click (think XP) to show all systray icons 
that are either active or interactive. 

to do this properly the systray applet needs a bit more smarts and needs to be 
able to expand/contract and hide/unhide icons. not too tricky, and something 
i was able to accomplish in a few hours of hacking about on it.

but we also need to extend the icon <-> systray communication. the program 
responsible for the systray icon needs to be able to attach some metadata for 
the systray to use (e.g. it's in an active state), and this needs to be done 
in such a way as to make the systray able to react in real time to these 
changes. i'm heavily in favour of extending the KSystemTray class to have 
methods that allow setting the state, which then uses dcop to communicate 
with the system tray. yes, this means it would be KDE specific (until DBUS 
becomes a reality) but doing it via X atoms and the like really looks ugly. 
bleh.

we may also want to allow the systray to talk to the icons in a direct fashion 
(something that's not so easy thanks to the QXEmbed class and raw X juggling 
that is used for this hack we call a system tray). honestly, if it was up to 
me and i didn't care about non-KDE systray icons i'd say we dump the whole X 
embeding stupidity and make it a 100% DCOP interface, where the systemtray 
owns the icons, creates the menus, etc.... all via a set of DCOP calls that 
apps can access, transparently to them via the KSystemTray class. 
unfortunately, reality dictates we have to hobble it to work with other 
systems that aren't as good as KDE and lack anything sane resembling DCOP 
and/or reasonable icon handling. if there was ever a reason to say "Screw the 
rest of the X11 world of braindamage, let's make KDE work in spite of them" 
the system tray is it. that's the idealist in me, the pragmatist realizes 
that isn't an option (at this point in time).

anyways, long ramble, but i hope i got my idea across, namely: this requires 
some API changes, some more invasive than others, and a good overhaul and 
extension to the systray applet's capabilities. this may even require some 
BIC changes.

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

iD4DBQE/mGsz1rcusafx20MRAr23AJiXTMzyLrG52gegIfArKwg2tp/TAJ9rkA66
rbfcYBdXU9FfkbKczcBnPw==
=u4f2
-----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]