If I use the context menu of a taskbar entry (e. g. "Close" to close a window), then the taskbar doesn't hide iteself after that menu is closed. Reproducible: Always Steps to Reproduce: 1. Change the taskbar to be in "Auto-Hide" mode 2. Right-click a taskbar entry and choose "Close" Actual Results: The taskbar should be hidden Expected Results: The taskbar is shown [~] $ xfwm4 --version This is xfwm4 version 4.2.2 for Xfce 4.2.2 built with GTK+-2.4.9, linked with GTK+-2.4.9.
That's a know gtk problem, it's not an xfce bug.
Ok, thanks for this information. Changed the status to "INVALID" (hope this is ok).
We *could* fix this, though, couldn't we? Just hook the 'deactivate' signal of the menu, and do a check to see if autohide needs to be activated, based on mouse position. I believe I do something similar for Xfmedia. I don't think this is really a problem with GTK - I assume the autohide uses mouse leave events to check for autohide, but when you have the menu open, it doesn't strictly leave.
I do that for the panel menus as well. I think the menu is opened from the netk-widget though and the widget doesn't know about the taskbar window, nor does the taskbar window know about the netk-tasklist widget implementation (the menu). Perhaps we could add a menu-deactivated signal to the netk-tasklist widget.
I disagre. What you suggest is a hack to work around an X/GTK limitation (acknowledged by the GTK people IIRC)
So? Is it going to be fixed if we don't work around it? I think not.
(In reply to comment #6) > So? Is it going to be fixed if we don't work around it? I think not. Right, but is it better to add hacks and hooks all over the place in Xfce? Let's not forget that it needs to be fixed also in the panel tasklist plugin, and there the hack would be even more tricky IMHO. Just my 2 cents anyway.
Xftaskbar is deprecated, so I don't think this is going to be fixed in the near future. -H-