GNOME Bugzilla – Bug 81041
Auto-hidden panels need to show themselves when focused
Last modified: 2020-11-06 20:25:32 UTC
When a hidden panel receives focus (e.g. when you've cycled to it by using Ctrl-Alt-Tab in Metacity, or whatever you've set up in Sawfish), it ought to unhide itself, you shouldn't have to press the 'show' button. In the window cycling case, if you continue to cycle past a hidden panel, it should hide itself again automatically if it was hidden before. Especially right now when all panels have the same name, this is really needed as there's no way to distinguish panels when you're cycling through them other than being able to see what's on them. Whatever happened to that 'user defined panel names' feature, or at least generating distinct default names for each new panel....? Now that I've written this it sounds like it's more likely to be the window manager's job, but I'll let somebody who actually knows decide that and assign it to Metacity and Sawfish as appropriate :)
Calum: friendly reminder to add the GNOME2 keyword when you are submitting bugs. :)
Fixed in CVS. We just autoshow it when it receives focus.
Turns out Mark only implemented this for auto-hiding panels-- it should also work for panels that have been explicitly hidden using the panel's hide buttons. Re-opening at Mark's request.
If I am ctl+alt+tabbing around, the panel only unhides if I stop on it. It seems like this would be more useful if it unhid when I ctl+alt+tabbed to it, whether or not I 'stopped' on it. [I realize this is completely unclear, but I'm not quite sure of the right terminology to use here...]
Indeed, that's the behaviour I'd expect as well... I hadn't been able to test it as the build I'm running is from before mark's patch. Installing a newer one as we speak... Ideal behaviour should be to unhide the panel as you 'land' on it while cycling, and hide it again only if you decide to cycle past it. (This does sound like it could be tricky to implement/non-intuitive for autohiding panels, though, as if you cycle to one, you presumably then have to physically move the mouse into it and back out to make it disappear again).
Calum: I'm also not sure that metacity really supports this behavior; it is one of my personal irritations with metacity that instead of bringing window-to-front on cycle it just does that focus indication line. Not sure, though- there may be a way to force it.
Havoc: you're input would be useful on two things in this 1) I tried auto showing a hidden panel when we get a FocusIn. But unfortunately Metacity seems to provoke a FocusIn event when the panel already has focus and you hit ctrl-alt-tab. What happens (I think) is that Metacity does a grab and we get a FocusIn with mode=NotifyGrab. gdk doesn't ingore this anymore and hence a GdkEventFocus is generated. Have a look at the comment in gnome-panel/basep-widget.c (basep_widget_focus_in_event) 2) I'm right in saying there's no way for the panel to receive notification when the user is ctrl-alt-tabbing around the panel windows, right ? i.e. we can't do this auto-showing until the user actually drops focus onto the panel ?
1) is a metacity bug, I'm not sure why I have it working that way. display.c:meta_display_begin_grab_op() should probably grab on the display->no_focus_window when the grab isn't an operation on a specific client. I'm not sure why it works the way it does, I must have written it at 3am. Anyway you could work around it by just ignoring focus in with NotifyGrab, assuming GDK exports that, maybe it doesn't. 2) Yes, if you want to raise/unhide the panels as you're going through them, you would probably need a window manager feature. The simple thing is that metacity could actually activate/focus/raise windows as they were selected in alt-tab, then you'd get focus in; but if metacity just raised them, we'd probably need a way to send the panel an "unhide" message. The raise-all-windows-as-you-cycle thing still seems to create a really jumpy and unstable interface to me though, all kinds of stuff flying around your screen while you're just trying to move forward to the only window with a certain icon, or something... I dunno.
Just thinking about this last night, maybe the behaviour you currently get when cycling windows would work just as well (if not better) for panels, without trying to do any fancy panel show/hide tricks-- i.e. just show the black outline of the panel you would end up on if you stopped cycling. Obviously that way you wouldn't get any clues about what's on a hidden panel unless you actually released Ctrl-Alt-Tab and gave it focus... but I'd guess most people probably only use two or three panels and arrange their contents according to their position, so just seeing the frame's position would probably be a good enough cue in most cases.
Similarly, if a drawer is closed you do not get any visual indication that the drawer will be focused. Also, the drawer is not opened when it is focused.
Havoc: no, gdk doesn't export XFocusChangeEvent:mode ... Calum: a conclusion, as always, would be nice :-) I have no clue what to do about drawes :/ Maybe setting the window icon to be that of the drawer, and setting the title to drawer would be at least some way useful to the user.
mark: yes, conclusions would be nice, but unfortunately it's hard to draw any before somebody prototypes any of the suggestions so we can play with them and find out why they either a) can't be implemented or b) actually suck in practice :) For consistency, I'd be happy enough to see my last suggestion implemented: panel/drawer outlines being shown as you tabbed through them. If the panel/drawer is hidden, though, the outline of the unhidden panel/drawer needs to be shown, not just a line drawn around its hide button. I'm not sufficiently clued-up to work out whether that's feasible or not from Havoc's comments, though. Your suggestion about the icon/name shown in the cycling popup is also good and should be implemented too, if possible. Though we're still really missing the ability for the user to choose panel names so they don't all show up as "panel" (or "drawer", in this case) :/
Not on bill's list; punting to 2.0.2.
*** Bug 87406 has been marked as a duplicate of this bug. ***
Havoc, what's the feasibility level on my last suggestion here? That is, drawing the "as they will appear if you unhide it" outline of hidden panels as you Ctrl+Alt+Tab through them, rather than just outlining its hide button (if it even has one) as you do now?
Okay, we're back to square one with this. My original solution was far to simplistic. See #83476 fo for problems thrown up and good dialog on how to for about fixing this properly. I know this bug was originally about explicitly hidden panels, but it has since moved to just talking about auto hidden panels. I'm re-titling, but I'll log another for explicitly hidden panels. Note this will be dependant on another gtk+ bug I'll log that either gtk+ should ignore FocusChanges with NotifyGrab or provide a way for the application to ignore them. 2002-07-27 Mark McLoughlin <mark@skynet.ie> * basep-widget.c: (basep_widget_focus_in_event): remove bogus autoshowing on focus that was supposed to fix #81041. Ths solution for this needs a lot more consideration - see #83476 for issues.
Status? We need to know what to plan for here.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Gnome Panel 2.6, Fedora 2, Sawfish 1.3: auto-hidden panels should be always on top, so that they shows up when focused. Not sure if this is be the same bug, the the behavior of Gnome Panel 2.4 was that; for 2.6, the Panel stays bellow other windows until you click them.
This is actually fixed in 2.8.0 as far as I can make out
Not quite; for me at least, in 2.8.0 auto-hidden panels still don't unhide while you're cycling, but only if you happen to land on one at the end of your cycle. That was specified in my original report: "In the window cycling case, if you continue to cycle past a hidden panel, it should hide itself again automatically if it was hidden before." Nor has the alternative (if not quite so good) proposal been implemented: drawing the focus outline where the panel *would* unhide to, rather than actually unhiding it only to have to re-hide it when the user immediately pressed Ctrl-Alt-Tab again. You might consider this not worth bothering about, but in that case I'd rather see the bug closed for that reason rather than saying it's fixed when it's not :)
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Calum: I don't think we can do anything without metacity help since the panel is not aware of the Ctrl-Alt-Tab stuff. So here's the choice: * close the bug * bribe the metacity people so they add some magic for the panel What do you think is better? (I don't have any money to bribe the metacity people)
My suggestion is: - wait for a compositing manager window manager - at that point we can redo what alt+tab looks like, including this - the panel might have to set a hint so the compositing WM knows to treat it this way (or the WM could even handle the hiding in the WM itself) This could be prototyped with luminocity or metacity+ssp-patches today, and hopefully will be production quality in a year or two. If we think it's important enough the short-term approach would be for the WM to set a hint like "_NET_UNDER_FOCUS_CONSIDERATION" as each window is being cycled past.
It's less of an issue now that all panels have sensible default names that show up while you're Ctrl-Alt-Tabbing. Would still be nice to revisit at some point, though.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.