After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710304 - support multiple monitors per box
support multiple monitors per box
Status: RESOLVED WONTFIX
Product: gnome-boxes
Classification: Applications
Component: display
unspecified
Other Linux
: Normal normal
: 3.22
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
: 686780 (view as bug list)
Depends on: 732098
Blocks:
 
 
Reported: 2013-10-16 16:30 UTC by Matthias Clasen
Modified: 2016-03-31 13:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
topbar: Remove dependency on App and AppWindow singletons (5.00 KB, patch)
2014-06-21 07:38 UTC, Adrien Plazas
none Details | Review
searchbar: Remove dependency on App and AppWindow singletons (3.84 KB, patch)
2014-06-21 07:38 UTC, Adrien Plazas
none Details | Review
searchbar: Remove dependency on App and AppWindow singletons (3.85 KB, patch)
2014-06-21 08:29 UTC, Adrien Plazas
none Details | Review

Description Matthias Clasen 2013-10-16 16:30:40 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.
Comment 1 Christophe Fergeau 2014-03-14 09:47:44 UTC
*** Bug 686780 has been marked as a duplicate of this bug. ***
Comment 2 Jakub Steiner 2014-06-03 14:55:12 UTC
Can you provide a use for the virtualized multi-monitor environment?
Comment 3 Zeeshan Ali 2014-06-03 15:48:25 UTC
(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.
Comment 4 Matthias Clasen 2014-06-03 16:41:20 UTC
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.
Comment 5 Jakub Steiner 2014-06-04 08:55:22 UTC
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
Comment 6 Lasse Schuirmann 2014-06-04 08:59:37 UTC
(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
Comment 7 Adrien Plazas 2014-06-21 07:38:20 UTC
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.
Comment 8 Adrien Plazas 2014-06-21 07:38:24 UTC
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.
Comment 9 Adrien Plazas 2014-06-21 08:29:35 UTC
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.
Comment 10 Lasse Schuirmann 2014-06-21 08:35:25 UTC
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.
Comment 11 Lasse Schuirmann 2014-06-21 08:35:28 UTC
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.
Comment 12 Lasse Schuirmann 2014-06-21 08:57:42 UTC
Review of attachment 278882 [details] [review]:

Commit log: see review of previous patch.
Comment 13 Adrien Plazas 2014-06-21 09:07:22 UTC
"Setup the topbar" is a temporary solution until I fix AppWindow too, but you're right, temporary solutions shouldn't be messy.
Comment 14 Zeeshan Ali 2014-06-23 12:30:48 UTC
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.
Comment 15 Lasse Schuirmann 2014-07-08 11:08:27 UTC
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.
Comment 16 Zeeshan Ali 2015-02-23 18:55:43 UTC
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.