GNOME Bugzilla – Bug 710304
support multiple monitors per box
Last modified: 2016-03-31 13:22:07 UTC
When creating a vm, offer to attach more than one monitor When connecting to a vm that has multiple outputs, show the primary display by default, and offer a 'monitor switcher', which could be similar to the workspace switcher in gnome-shell, or could just be a menubutton with previews. Allow to 'bind' an external display of the host to a vm in the display configuration. In this case, put up a fullscreen window on the external display showing the secondary output of the vm, while the normal boxes window would continue to show the primary output.
*** Bug 686780 has been marked as a duplicate of this bug. ***
Can you provide a use for the virtualized multi-monitor environment?
(In reply to comment #2) > Can you provide a use for the virtualized multi-monitor environment? IIRC, this idea mainly was mccann's so I'll put him in CC here.
I think one idea was that you could actually map the multiple virtual monitors to your physical monitors - in that case you wouldn't need a monitor switcher, obviously. But if you then later run that same vm with the external monitor unplugged, you may end up with more virtual than physical monitors.
Ah. So at a first glance I feel the 'lost a host display' map fairly well to the 'disconnected an actual display'. I guess every OS has a way to deal with that. I have a feeling creating a special UI to switch virtual monitors, dealing with cases of apps showing windows on virtual displays that aren't visible is something we better steer clear of. So let's focus on the two main use cases for multimonitor: * Run multiple VMs at the same time, each on a different physical display * Run a single VM spanning multiple displays
(In reply to comment #5) > Ah. So at a first glance I feel the 'lost a host display' map fairly well to > the 'disconnected an actual display'. I guess every OS has a way to deal with > that. > > I have a feeling creating a special UI to switch virtual monitors, dealing with > cases of apps showing windows on virtual displays that aren't visible is > something we better steer clear of. > > So let's focus on the two main use cases for multimonitor: > > * Run multiple VMs at the same time, each on a different physical display > * Run a single VM spanning multiple displays I agree. A minor addition: * Run multiple VMs at the same time, each on a different window with the ability to fullscreen any window
Created attachment 278880 [details] [review] topbar: Remove dependency on App and AppWindow singletons Replace handling of parent singletons in Topbar with signals and properties, let the parents handle the connsequencies.
Created attachment 278881 [details] [review] searchbar: Remove dependency on App and AppWindow singletons Replace handling of parent singletons in Searchbar with signals and properties, let the parents handle the connsequencies.
Created attachment 278882 [details] [review] searchbar: Remove dependency on App and AppWindow singletons Replace handling of parent singletons in Searchbar with signals and properties, let the parents handle the connsequencies.
Review of attachment 278880 [details] [review]: Summary line is a little long. How about "topbar: Remove App and AppWindow dependencies"? Maybe zeenix knows a better alternative, he does every time. connsequencies -> consequences. Code looks good as far as I can see. ::: src/app-window.vala @@ +87,3 @@ } + + // Setup the topbar I think I'd move this into an own function. This reduces the complexity of the function, therefore makes AppWindow easier to understand. I imagine AppWindow () like this: init_window (); restore_position_and_size (); setup_topbar (); setup_searchbar (); // introduced by your next patch I don't know how zeenix sees this but for me this would be way easier to read. So don't do anything here until zeenix agrees/disagrees.
Review of attachment 278882 [details] [review]: Commit log: see review of previous patch.
"Setup the topbar" is a temporary solution until I fix AppWindow too, but you're right, temporary solutions shouldn't be messy.
I've created a separate bug for multi-windows, which is very different from what this bug is about: bug#732098. All multi-window related patches should go there. About this bug, I think we really don't need to add any complicated UI for assigning external displays to VMs after bug#732098 is resolved since then user can always easily size and position the VM as they wish, e.g fullscreened on a secondary monitor or spanning across multiple monitors etc. i-e Lets not go for the last para of comment#0. However, there is still the case of remote displays and remote VMs that already has multiple displays define and so I'll keep this bug for that case. Instead of some complicated UI, we could have easy ways to switch between different displays of the same box. This would be the first part of the comment#0.
IIUC the patches here are obsolete, aren't they? Kekun, can you mark them as such if this is the case? I also change title to mirror the more exact meaning of the bug. In addition I mark this needinfo because there is need to discuss how we want this feature to be exactly. IIRC in our discussion on IRC we basically decided to postpone this until multi-boxes (Bug #732098) is solved which also blocks this because of the needed refactoring.
Lasse, putting bugs in NEEDINFO is usually only useful if its clear who the info is needed from. :) IIRC, after talking to jimmac, the conclusion was that we don't do anything more than mutli-windows (which we already support now). i-e If a remote display has multiple monitors, tough luck. Please do re-open with patches.