GNOME Bugzilla – Bug 103223
Notification Area needs keynav
Last modified: 2015-03-24 13:00:56 UTC
The notification area is a feature that we have promised for 2.2 and a lot of applications have started using it. It is much more user friendly to have the notification are sitting on the panel waiting to be used than to have to find out where it is, what it's called and how to add it to the panel. It should "Just work" Someone said that they don't want to have an extra drag handle on the panel by default. If it is added to the right of the window list it is totally un-noticable.
Um, hold on - this was already discussed and the best solution I saw was: http://mail.gnome.org/archives/desktop-devel-list/2003-January/msg00125.html Why file a bug which ignores a previous discussion on the subject ? That's rather annoying ... Removing TARGET2.2.0 - its not going to be for 2.2.0
WEll if some of the panel applets where switched to notification area icons, i'd say the ideal location for the notification area is next to the clock on the top panel.
moving to GNOMEVER2.2
Moving to GNOMEVER2.3 - We should probably aim to have the notifiaction area working better and on the panel by default for 2.4. Especially now that a lot of apps in the core desktop use. eg. a11y
Mark: accessibility doesn't use the notification area. One reason for this is because keyboard navigation appears to be broken for the notification area. So if it *is* included by default, I believe some fixes are required to make it fully keyboard-navigation-friendly. My recollection is that it breaks TAB and arrow navigation of the panel, and you can't get to the notification area objects' menus from the keyboard. Not sure if this is the case now since my build of the notification area is a bit stale.
Marking GNOMEVER2.5 and accessibility. A lot of apps, including some that we are likely to be shipping now use the notification area, and redhat and ximian put it on the panel by default AFAIK. Would be nice to get the A11y stuff fixed before 2.6. Playing with the notification area in 2.4 tabbing and arrowing on the panel works fine with the notification area but it is impossible to get to the context menu for notification area applets.
Updating status whiteboard to reflect a11y team's assessment of priority.
*** Bug 155521 has been marked as a duplicate of this bug. ***
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
upgrading priority as the notification area is gaining in importance.
Putting this on the 2.12.x milestone- we won't ship with this broken by default again.
Created attachment 51075 [details] [review] adds notification area to the default layout This is not tested yet (I'm updating my jhbuild installation right now). Will test it soon and ask permission for ui freeze breakage.
Tested and committed (release team approved). Retitling for the keynav and unsetting the GNOME milestone (I don't think it's a showstopper anymore, is it?).
This is a big issue for accessibility still - the notification area needs to be keyboard navigable! Anyone available for a patch?
Mass changing: milestone 2.12.x => milestone 2.14.x
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
*** Bug 372815 has been marked as a duplicate of this bug. ***
*** Bug 395669 has been marked as a duplicate of this bug. ***
Any progress on this front? It's a pretty significant issue, especially for users who are blind. Thanks in advance!!!
Today a user on the Orca (screen reader) list posted the following: > It seems that the panel notification area in Gnome 2.18 as shipped > with Ubuntu Feisty has taken a major step backward with regard to > accessibility when compared with 2.16 in Edgy. I used to be able to > access programs in the notification area, albeit by trial and error, > by counting the times the flat review said `panel'. Now in 2.18 this > is impossible, since the entire notification area is seen by Orca as a > single object and I can no longer even guess at a program inside it, > since the flat review is either on the notification area or it isn't. > It can no longer detect anything that is inside the notification area > at all. Is this a known bug? Is a fix on the way? Or is there another > way to access the programs running in the notification area that I am > currently unaware of? It would be EXTREMELY helpful to have keyboard access to the notification area so that we can provide access to its contents. Sorry to be a noodge, and thanks (again) in advance for your help!!!
This bug is becoming more and more of a problem for those of us who are blind and exclusively use the keyboard to navigate. Apps that I can think of that I can't access correctly because of this include nm-applet, the gaim applet, the ekiga applet, and so on. I'm really hoping that this can be addressed for 2.20. thanks muchh
I'm CC'ing Patrick Wade on this to see if he has any insight. Patrick? Want to be a hero on a horrible bug that's over 4 years old? :-)
I'm marking the priority of this as "Urgent" since the lack of keyboard navigation affects the usability of gnome-panel by people who cannot use the mouse. We desperately need this fixed, and we constantly get complaints and questions about why this is broken in gnome-panel.
I thought I had put a comment about this, but it seems it's not the case. I know this bug is important, but I probably won't have time for it in the short term. Outside help is really welcome.
(In reply to comment #24) > I thought I had put a comment about this, but it seems it's not the case. I > know this bug is important, but I probably won't have time for it in the short > term. Outside help is really welcome. You bet Vincent! We're recruiting internally and hopefully have found someone to investigate.
I'll have a looksy at this one.
(In reply to comment #26) > I'll have a looksy at this one. > Hey Patrick - thanks so much! Any luck with this one?
I took a look at this. Seems notification area acts as both a gtkplug and a gtksocket: gtkplug to communicate with gnome-panel, gtksocket to communicate with applications which would create an icon on panel.(not sure if I am right on this). When focus signal comes, both the gtkplug and the gtksocket are noticed by gdk_event_apply_filters. So the "focus" signal are handled twice and the focus just jump out to the next widget.
I guess , gdk_event_apply_filters is called twice, for two different GtkEvents trigger it. the two events have diffent addresses saved in field window, print by gdb like this: the first event: {type = GDK_NOTHING, window = 0x8078960, send_event = 1 '\001', in = 0} the second event: {type = GDK_NOTHING, window = 0x8078b70, send_event = 1 '\001', in = 0} it is a GdkWindow object , how can I get the gtk object ? or other useful things through this address ? THX!
li.yuan@sun.com and I have found the reason :) Generally, An application uses a GtkImage to show picture. The image object has can not be focused by default. i.e. GTK_WIDGET_CAN_FOCUS(GTK_WIDGET(image)) == FALSE. So When the application's plug object handles FOCUS_IN message, it can not find a GTK object to grab the focus, so it generates message GTK_DIR_TAB_FORWARD back to the area process. The area will try the next application's plug.If all the applications' plug can not grab focus, the focus will be moved out. It is very reasonable. We use stardict to reproduce this bug, and stardict's trace is :
+ Trace 154811
------------------------------------------------------------ To solve this bug, the application's image object should have the property GTK_CAN_FOCUS . We modified the stardict's code by setting the image : GTK_WIDGET_SET_FLAGS (image, GTK_CAN_FOCUS); then the image can grab the focus when we use tab to move the focus onto it. Of cause, in this simple way we can not see it performs perfectly like a button.
And we plan to make a patch for gtkstatusicon, we will also support keyboard shortcuts. For those applications embed image into gnome-panel without using statusicon, they need to fix this by themselves.
Created attachment 93708 [details] [review] patch to add focus indicator on tray icon and handle shortcut keys in status icon Hi Matthias, would you like help me to review the patch?
Should the bug be moved to gtk+ or is a patch needed for the notification area too?
There will not be a patch for notification area I think. But it is not only a bug in gtk+. Some applications has their own way to add icons in notification area instead of using gtkstatusicon. So I'm not sure where this bug should be...
Well this bug is old, have been used for many things and is against gnome-panel. A new bug for GTK+ might be better.
Did the patch ever make it over to a gtk+ bug?
Please refer to http://bugzilla.gnome.org/show_bug.cgi?id=473786
Seems to be working now, thanks to GTK+ being fixed. Please reopen if I'm missing something.