On Fri, 2013-07-05 at 11:01 +0200, Bastien Nocera wrote: > > Which is exactly one of the reasons why focus-follows-mouse isn't an > option we offer/isn't supported.
Focus-follows-mouse makes it worse (especially when it's a trackpad, and a large screen, and a small application like empathy which happens to be on the *other* side of the screen for where its bizarrely detached menu now lives. But it's a fairly horrid user experience even without that. I still didn't even know it was *there* because it was miles away from where I was actually *looking*, when I was using the application. Are we also deprecating non-maximised windows? Perhaps that might make the 'app menu is not in your app' thing make sense? > In the meanwhile, you can move the menu back inside the window itself: > https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/README.xsettings Ah, that's really useful; thanks. For those playing along at home, that's: gsettings set org.gnome.settings-daemon.plugins.xsettings overrides \ "{ 'Gtk/ShellShowsAppMenu': < 0 > }" ... and then restart both gnome-settings-daemon and gnome-shell, it seems. Well, it'd be *more* useful if I hadn't given up on empathy and the gnome-shell telepathy integration already and gone back to using pidgin because it actually works, and it actually *shows* me when it isn't connected, rather than trying to avoid confusing me with those scary technical details like the fact that I cannot be reached by my colleagues. But although empathy is the only application in which I'd discovered this problematic "menu elsewhere", I'll leave it disabled just in case some *other* applications now regain some missing functionality in their *own* window, where I naturally expect it to be. Thanks. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
