thoughts on the systray

Aaron J. Seigo aseigo at kde.org
Mon Feb 14 10:44:13 GMT 2005


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 keyboard 
access. one of the blockers to getting that done for 3.4, actually =(

> And maybe it would even make sense for screen readers to implement 
> 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, 
perhaps? press that combo and you get your systray contents? 

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

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

-- 
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/0eeec1d4/attachment.sig>


More information about the kde-core-devel mailing list