--nextPart7296789.LCGdQQELQt
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

[Aaron J. Seigo, Sonntag, 13. Februar 2005 23:58]
> 	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.

I agree that the host application should have full control over the user=20
interaction. It should be far easier to make Kicker fully accessible this=20
way. 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=20
it.

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

Olaf

=2D-=20
KDE Accessibility Project

--nextPart7296789.LCGdQQELQt
Content-Type: application/pgp-signature

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

iD8DBQBCEGmFoLYC8AehV8cRAitgAJ9Zpacun932yBoI8hcrP70ybDVHMACgtUvv
9xA4DQBD6JNNUCcpb8SuT5E=
=AnTU
-----END PGP SIGNATURE-----

--nextPart7296789.LCGdQQELQt--