| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to solve several problems with sizing and resizing displays, a
'map' handler was added to VirtViewerDisplay. The first time the map
handler runs, its queues a resize to attempt to ensure that the window
gets created at its desired size. Subsequent map events generate a call
to _make_resizable(), which was an attempt to ensure that the window was
always 'shrinkable' on the Microsoft Windows platform. Recent testing
suggests that this _make_resizable() is not actually necessary on
Windows anymore, since it is possible to shrink the display even when
this call is removed.
In addition, the call to _queue_resize() is a bit of an indirect
solution to the problem of ensuring the proper size at startup. What we
really want is to guarantee that the very first size request negotiation
returns the desired size rather than the minimum size. In order to do
this, we've added a flag to determine whether we've ever received a size
request, and if not, we return our desired size, even if 'dirty' is not
set.
|
| |
|
|
|
|
|
| |
g_object_get(...) can be cumbersome, so add convenience API for getting
the display ID ("nth-display") property:
virt_viewer_display_get_nth()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 6edde5786 introduced a regression wrt shrinking windows on windows
guests. This seems to be because resizing a display often causes the notebook
widget to switch to the status page temporarily (often so quickly that it's not
noticeable to the eye). This causes a quick 'unmap' and 'map' event sequence on
the display widget. Apparently the timing of these events varies enough between
linux and windows guests that it is only noticeable on windows gueststhe timing
of these events varies enough between linux and windows guests that it is only
noticeable on windows guests. The exact sequence that causes the bug appears to
be as follows:
1 user resizes window smaller
2 display widget gets a new allocation, which causes it to send a display
reconfiguration to the guest
3 client receives a new show-hint for the display which causes it to switch
temporarily to the 'status' notebook page
4 display widget gets unmapped
5 Client receives another new show-hint, which causes the display widget to get
re- mapped, which causes client to send a display reconfiguration to the guest
(using the old size)
6 client receives new (smaller, from step 2) display size and temporarily
changes to the new size
7 client receives new (larger, from step 5) display size and changes back to
original size.
To fix the issue, we only explicitly request a resize in response to the very
first map event, and for any subsequent map events, we simply call
_make_resizable() as before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rhbz#1104064 had a couple of symptoms. The first was fixed in
6edde57862ac30e74ce6412c93a2fa925ae4ea67.
The second symptom is that displays could also become tiny when clicking 'View >
Zoom > Normal Size'. This was because VirtViewerDisplay returned early from
_display_set_zoom_level() if the zoom level was being set to the current zoom
setting. However, the calling function (_window_set_zoom_level()) also tries to
queue a resize event for itself after setting the zoom level on the display. If
the display doesn't queue a resize event for itself, its size request will only
be 50x50 during the window resize negotiation. This causes the display to become
tiny and zoomed out. Queueing a resize on the display widget ensures that it
will request the proper size during the next allocation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When enabling a new display on linux guests, the new window would be tiny
(50x50) and zoomed way out. This was caused by the fact that when the display
widget received the 'map' event, it unconditionally cleared the 'dirty' flag,
which meant that it would only request 50x50 size. This behavior was intended to
fix a bug on the windows client which wprevented windows from resized smaller
than the guest display resolution. Unfortunately, due to the timing of the 'map'
and allocate events, the widget became very small.
Instead of clearing the 'dirty' flag directly when a widget is mapped, we
now queue a resize event, which will guarantee that the widget attains its
desired size and will then clear its dirty flag (allowing it to be resized).
Testing on windows indicates that this fix still solves the 'unshrinkable
window' problem while also preventing the tiny secondary display bug.
Resolves: rhbz#1104064
|
| |
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1107518
|
| |
|
|
|
|
|
| |
Previous commit accidentally broke gtk2 build by using
gtk_widget_get_preferred_size(). We can't simply use gtk_widget_size_request()
for the gtk2 build since this will generally return 50x50 whenever we're not in
the middle of a resize, so we need to add a compatibility function.
|
| |
|
|
|
|
|
| |
Remove "Automatically resize" menu item (always enabled for Spice
display now)
https://bugzilla.redhat.com/show_bug.cgi?id=1007649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't rely on spice-gtk to do any alignment of displays. This patch sets the
disable-display-align property on the SpiceMainChannel, and makes the
VirtViewerSession in charge of doing all alignment. This means that every
display has to tell the VirtViewerSession when its "virtual monitor" has changed
configuration (and wants to reconfigure its display on the guest), rather than
sending it directly to the Main Channel. The session will then align the
displays (if necessary), and the spice session will send down new configuration
for all displays at once. This solves a couple of problems:
1. It allows the session to send down absolute coordinates only in the case
where *all* windows are fullscreen (so that we can still support
vertically-stacked displays, etc). But it auto-aligns displays if only a
subset of the displays are in fullscreen mode. This solves the problem of
overlapping regions on different displays when one monitor is in fullscreen
because only one monitor's configuration was updated and the others were not
aligned.
2. Allows us to always align based on the current position of each display. This
contrasts with the earlier behavior where the position used for alignment was
the window's position at the time when it was last resized. This caused
displays to be arranged in a seemingly non-deterministic manner if one window
was moved and then another window was resized (causing a display
re-configuration).
Solves rhbz#1002156
|
| |
|
|
|
| |
When setting a display's zoom level to the same level as the current setting,
return early so that we don't notify about a property change
|
| | |
|
| |
|
|
|
|
| |
The fix 0dca975d64fcf0782ec7b3e3bd965f1bcf47c528 make the first window
unshrinkable right after start. Wait until the window is mapped and
remove the dirty-resizable state after (win32/gtk2).
|
| | |
|
| |
|
|
|
| |
Now that fullscreen state is no longer global to application, we need to
have the current state per display
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With gtk-2 we have a special hack, where at first we make the
virt-viewer-display request its actual size, and then once the window is
mapped, we request a size of 50x50 to allow the user to resize the window
to something smaller.
With gtk-3 >= 3.8.1 this is broken, and the window gets resized to a
smaller size as soon as we change the size request to 50x50.
gtk-3 has a much better way of dealing with this in the form of widgets
being able to specify both a minimal and a natural size. This patch changes
virt-viewer to use this with gtk-3, instead of the gtk-2 hack.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
| |
gtk_widget_get_mapped is only available in gtk+ 2.20, so we need
a compat definition for older releases.
|
| |
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
|
| |
Wait until the widget is actually on screen before removing its
size constrain. This solves 50x50 window secondary window size
when connecting to a multi-monitor spice guest.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fix some unwanted guest resize due to rounding issues (at least when
scaling up)
We may want to save the original remote desktop size, instead of
always checking widget requisition. That way zooming shouldn't resize
guest at all, but it seems tricky to handle that special case vs user
window resize that should trigger guest resize.
https://bugzilla.redhat.com/show_bug.cgi?id=856678
|
| | |
|
| |
|
|
|
|
|
| |
This property will be set when the display can be selected to be
"enabled" and shown (this can involve creating/connecting an
additional guest monitor, and may need guest agent cooperation for
example).
|
| |
|
|
|
|
|
|
| |
This flag will help to track whether the display has been
removed/closed and whether it really has a valid display.
Ready in contrast, is used to "hide" temporarily the display (when
starting or redrawing the display, to avoid artifacts)
|
| | |
|
| | |
|
| |
|
|
|
| |
Use round() instead of integer truncation when scaling the window,
to avoid floating point precision problems on i386
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When clicking the close button on a virt-viewer window with
a VNC session open, while the VNC session terminates, the
window does not go away.
The problem is that the virt_viewer_session_vnc_disconnected
method never gets invoked. The close button triggers a call
to virt_viewer_session_clear_displays which unrefs the
VirtViewerDisplayVnc instance. This in turn triggers a call
to gtk_container_destroy, which destroys all widgets it
contains, ie the VncDisplay * object.
With the VncDisplay object in its dispose phase, no signals
will ever be emitted, thus the 'vnc-disconnected' signal
never gets seen.
The design issue is that VirtViewerDisplayVnc is assuming
it owns the VncDisplay, whereas in fact the real owner is
the VirtViewerSessionVnc object.
The solution is to introduce a new virt_viewer_display_close
method which can be used to de-parent the widget before
VirtViewerDisplay is unref'd.
The VirtViewerSessionVnc object also needs to hold a full ref
on the VncDisplay object, not merely a floating reference
* virt-viewer-display-spice.c, virt-viewer-display.c,
virt-viewer-display.h: Add virt_viewer_display_close
* virt-viewer-display-vnc.c: Deparent VNC widget in
virt_viewer_display_close impl
* virt-viewer-session-vnc.c: Improve logging
* virt-viewer-session.c: Call virt_viewer_display_close
before unrefing display
* virt-viewer-window.c: Improve logging
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch there was a cyclic reference between VirtViewerSesion and
VirtViewerDisplay, since all VirtViewerDisplays are created / destroyed by
VirtViewerSession it is safe to assume that lifetime of VirtViewerSession >=
VirtViewerDisplay, so VirtViewerDisplay can take a borrowed reference
breaking the circle, and allowing proper cleanup on exit.
Note that there is no g_object_unref removed from virt-viewer-display, this
because there is no finalize / dispose and before this patch
VirtViewerDisplay never unref-ed the reference it hold to the session.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
If auto-resize is enabled, the guest desktop size will be resized to
match current window*zoom size.
This can be a problem if the user explicitely set the desktop size to
a different resolution and want to keep it. Disabling auto-resize
sounds like a simple way to allow that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The standard SPICE widget guest resize implementation does not
take into account the zoom level settings in virt-viewer, because
it has no knowledge of this functionality. The guest resize can,
however, be done by calling spice_main_set_display() directly.
This allows virt-viewer to resize the guest taking into account
zoom levels.
ie, if virt-viewer is run with --zoom 50 and the window
is resized to 400x300, then the guest agent should
be told to set its resolution to 800x600
|
| |
|
|
|
|
|
| |
The SpiceDisplay widget has built-in support for resizing the
guest desktop, but this does not know that virt-viewer has a
zoom level setting. This makes the virt-viewer zoom completely
inoperable. Revert use of the 'resize-guest' property.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Override the grab_focus() method in the display class. Since both VNC
and Spice displays are the direct child, let's just grab the child.
It can be that this behaviour need to be overriden if Spice or VNC
display become more complex (using sub-childs or different objects)
|
| | |
|
| |
|
|
|
| |
This is the method we prefer, even though we can't keep aspect ratio.
We could eventually support aspect ration in spice-gtk.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
To facilitate introduction of multi-head support, pull some of
the VirtViewerDisplay class out into a new VirtViewerSession
class.
|
| |
|
|
|
|
|
| |
Add many signals to VirtViewerDisplay which are emitted when various
events occur. This lets us remove all the code in the VirtViewerDisplay
subclasses which call back into VirtViewer methods. Instead VirtViewer
can simply connect signals to the display
|
| |
|
|
|
| |
Turn VirtViewerDisplay into a Gtk widget instead of just a GObject,
by merging the functionality from VirtViewerAlign
|
|
|
All source files must be named
virt-viewer-XXXX
All methods named
virt_viewer_XXX
|
