| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
The 3.0 release was the last one that still supports GTK2. For the
Windows builds the support to GTK2 was dropped in the previous release.
Let's do the same for the entire project now.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nowadays the value for MIN_DISPLAY_{WIDTH,HEIGHT} is 50. This arbitrary
value doesn't bring any benefit, doesn't provide a useful size for a
desktop to be usable and can actually trigger some undefined behavior
when reaching resolutions that are lower than the ones provided by the
video drivers (as in rhbz#1296878).
In order to avoid these issues and provide a minimum resolution that can
still be useful for our users, let's use the same values for minimum
width and height used by the linux QXL drivers (320x200).
This also requires us to adjust the minimum requested widget size when
zoom is enabled so that we don't accidentally request a size smaller
than the driver can support.
Related: rhbz#1296878
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, there was a single function for controlling the enabled
state of a display: virt_viewer_display_set_enabled(). Unfortunately,
this function is used for two slightly different things:
A. It informs the local display widget that the display has become
disabled or enabled on the server. In other words, it tries to
synchronize the 'enabled' state of the local widget with the actual
state of the remote display.
OR
B. It tries to actively enable a currently-disabled display (or vice
versa) due to some action by the user in the client application.
This causes the client to send a new configuration down to the
server. In other words, it tries to change the state of the remote
display.
There is some conflict between these two scenarios. If the change is due
to a notification from the server, there is no need to send a new
configuration back down to the server, so this results in unnecessary
monitor configuration messages and can in fact cause issues that are a
little bit hard to track down. Because of this, I decided that it was
really necessary to have two separate functions for these two different
scenarios. so the existing _set_enabled() function will be used for
scenario A mentioned above. I added two new
functions (_enable() and _disable()) that are used to send new
configurations down to the server.
|
| | |
|
| |
|
|
|
|
|
| |
g_object_get(...) can be cumbersome, so add convenience API for getting
the display ID ("nth-display") property:
virt_viewer_display_get_nth()
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Now that fullscreen state is no longer global to application, we need to
have the current state per display
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| | |
|
| |
|
|
|
|
|
| |
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)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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
|
