<div dir="ltr">Hey Jonathon,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 22, 2014 at 4:59 PM, Jonathon Jongsma <span dir="ltr"><<a href="mailto:jjongsma@redhat.com" target="_blank">jjongsma@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a patch series that attempts to fix rhbz#1032939. It's a pretty<br>
significant re-factoring of some of the multi-monitor handling code, so it<br>
requires careful review and testing.<br>
<br>
The current design of virt-viewer is that we have a VirtViewerWindow object<br>
(the "main window") that is shown at startup in order to communicate<br>
session-level connection status to the user. This window is stored in a hash<br>
table with a key being the ID of the display (#0, the first display). When we<br>
receive a new spice message indicating the maximum number of monitors available<br>
(e.g. 4 in the case of a linux guest with QXL), we create display objects for<br>
each of these remote displays, and signal that a new display was added. In<br>
resonse to this signal, we look up the window associated with this display's<br>
ID. If the window exists (as it does with display #0), we associate the display<br>
with that window.  Otherwise, we create a new window, and insert it into the<br>
hash table with the display's ID.<br>
<br>
Usually the first display on the guest is enabled, so this works out OK. But<br>
in cases where the first display is disabled on the guest, we end up with a<br>
"main window" that is blank and simply displays the message "Waiting for<br>
display 1...".<br>
<br>
The approach taken in this patch series is to remove the explicit association<br>
of an ID with a particular VirtViewerWindow. In other words, we no longer<br>
maintain a hash table of windows that associate a fixed id with the window<br>
object. Instead, we have a simple list of windows, and the ID of that window is<br>
determined by the ID of the VirtViewerDisplay object that it contains. In<br>
addition, we only create a VirtViewerWindow object for the display when the<br>
remote display becomes ready. Disabled remote displays do not have an<br>
associated VirtViewerWindow object until they become enabled. This means that<br>
the initial window (the "main window") can become any ID: it gets its ID from<br>
the first display that becomes enabled.<br>
<br>
Kiosk mode and Fullscreen mode require some additional handling, but I've<br>
tested both of them and they seem to work with this patch series.<br>
<br>
<br>
Jonathon Jongsma (4):<br>
  App: keep hash table of displays<br>
  VirtViewerDisplay: add convenience API for getting nth<br>
  VirtViewerApp: store windows in a list<br>
  Create windows on demand, not at startup<br>
<br>
 src/remote-viewer.c       |  14 +--<br>
 src/virt-viewer-app.c     | 296 +++++++++++++++++++++++++---------------------<br>
 src/virt-viewer-app.h     |   2 +-<br>
 src/virt-viewer-display.c |   6 +<br>
 src/virt-viewer-display.h |   1 +<br>
 5 files changed, 176 insertions(+), 143 deletions(-)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
1.9.3<br>
<br>
_______________________________________________<br>
virt-tools-list mailing list<br>
<a href="mailto:virt-tools-list@redhat.com">virt-tools-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/virt-tools-list" target="_blank">https://www.redhat.com/mailman/listinfo/virt-tools-list</a><br>
</font></span></blockquote></div><br>Doing a simple test here I found a regression. The first opened window is always a really small window (400 x something) and I have to resize it to a useful size manually. Can you reproduce it?</div>
<div class="gmail_extra"><div><br></div><div>Best Regards,</div>-- <br><div>Fabiano Fidêncio</div>
</div></div>