From kde-core-devel  Mon Feb 14 10:44:13 2005
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Mon, 14 Feb 2005 10:44:13 +0000
To: kde-core-devel
Subject: Re: thoughts on the systray
Message-Id: <200502140344.30027.aseigo () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110837795209782
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1338650.4kOTWoi9Te"

--nextPart1338650.4kOTWoi9Te
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 14 February 2005 02:03, Olaf Schmidt wrote:
> I agree that the host application should have full control over the user
> interaction. It should be far easier to make Kicker fully accessible this
> way.

yes. the current systray is a nightmare to get working properly with keyboa=
rd=20
access. one of the blockers to getting that done for 3.4, actually =3D(

> And maybe it would even make sense for screen readers to implement=20
> the system tray spec and to read out the information rather than painting
> it.

very good idea! have a key binding for it in the accessibility key bindings=
,=20
perhaps? press that combo and you get your systray contents?=20

> > 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")
>
> I am wondering whether even the context menu should be shown by the host
> application. Currently, all kicker applets have two context menus, with
> one of them being nearly inaccessible to users who need a bigger button
> size. Merging the two context menus would make the UI design far cleaner
> and more standard. But I know it is very difficult to achieve, because it
> would mean reworking the applet interface as well.

=2E.. and reworking it is something we can and should do for KDE 4.0 =3D) t=
here=20
are a number of issues with KPanelApplet that have emerged after several=20
years of (ab)use of it, so i fully expect KPanelApplet to get some=20
refactoring. context menus and accessibility are two factors that should be=
=20
considered.

=2D-=20
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

--nextPart1338650.4kOTWoi9Te
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCEIEN1rcusafx20MRAl4EAKCCn2ZrOfT+bcGA3lPolYQyXn0Q3wCbBy2s
TQcX0UtHcF8CVbNmqO6Bt24=
=6Nid
-----END PGP SIGNATURE-----

--nextPart1338650.4kOTWoi9Te--