Red Hat Bugzilla – Bug 843119
Change algorithm of --fullscreen window placement to avoid client primary monitor if possible
Last modified: 2012-09-04 17:58:43 EDT
Description of problem:
currently, when 'remote-viewer --full-screen=auto-conf URI' is called to connect to a single-monitor guest on two-monitor client, it places the newly created on the client primary monitor. This is quite WTF situation because all usual client desktop controls are obscured by the guest window. It's even more absurd in case of secondary monitor being larger than primary.
Because of ^, I propose an algorithm change that if client_monitor_count > guest_monitor_count, client windows shouldn't be placed on client primary monitor
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. connect to a guest with smaller screen count with --full-screen option
guest primary monitor is placed on top of client primary monitor
windows with guest monitors are places in a manner so that client primary monitor remains unoccupied.
This is not necessarily what is wanted when you have a big external primary screen and a small laptop secondary screen. I don't know if it's possible to know which screen the 'remote-viewer' command was run from, we could maximize there.
(In reply to comment #1)
> This is not necessarily what is wanted when you have a big external primary
> screen and a small laptop secondary screen. I don't know if it's possible to
> know which screen the 'remote-viewer' command was run from, we could
> maximize there.
This would be possible if remote-viewer launched windowed and then went fullscreent - the same path as with runtime fullscreen.
Anyway, things are easy with two-monitor client and single-monitor guest. It starts getting complicated (and annoying) when screen count grows.
Would you be fine with that? (fullscreen on the screen the command was run from) Or would you still wish for something more sophisticated?
> Would you be fine with that? (fullscreen on the screen the command was run from)
I'd prefer to have something more sophisticated to keep desktop controls on primary screen visible if possible (guest_displays < client_displays).
Then we'll get bugs because we are not using the better higher res screen but we insist on using the lower res screen instead. Probably better to go with something dumb but predictible.
I also think auto-conf should be as simple as possible and predictable. If you want to manually place screens, just don't use auto-conf, but move and maximize windows yourself, that should work. If it doesn't, then there is a bug.