summaryrefslogtreecommitdiffstats
path: root/src/virt-viewer-display.c
Commit message (Collapse)AuthorAgeFilesLines
* Drop support to gtk2Fabiano Fidêncio2016-02-151-106/+1
| | | | | | | | 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>
* display: Use correct variable namePavel Grunt2016-02-151-1/+1
| | | | Fix gtk2 build
* display: Remove zoom propertyPavel Grunt2016-02-151-24/+2
| | | | | It is possible to get the same info from the "zoom-level" property. virt_viewer_display_get_zoom() now returns TRUE if zoom level != 100
* display: Use common code to get preferred sizePavel Grunt2016-02-151-21/+31
|
* display: Set value of desktop width and height property directlyPavel Grunt2016-02-031-6/+2
| | | | | | | | | | Avoid calling gtk_widget_queue_resize() and emiting the "display-desktop-resize" signal. The only user of the properties is virt_viewer_display_spice_set_desktop() which will call the function and emit the signal after setting both "desktop-width" and "desktop-height" properties. Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* display: Return early and remove a blockPavel Grunt2016-02-031-21/+18
| | | | Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* display: Remove unnecessary VIRT_VIEWER_DISPLAY castPavel Grunt2016-02-031-6/+6
| | | | Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
* display: Set useful values for MIN_DISPLAY_{WIDTH, HEIGHT}Jonathon Jongsma2016-01-131-15/+18
| | | | | | | | | | | | | | | | | | | 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>
* display: set min value for desktop-{width,height} props as ↵Fabiano Fidêncio2016-01-081-2/+2
| | | | | | | | | | | | MIN_DISPLAY_{WIDTH,HEIGHT} Otherwise we can have warnings when resizing the virt-viewer window to the smallest possible size, like: (virt-viewer:11187): GLib-GObject-WARNING **: value "50" of type `gint' is invalid or out of range for property `desktop-height' of type `gint' Related: rhbz#1296878
* Add new functions to enable/disable a displayJonathon Jongsma2015-09-101-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* coverity: result is not floating-pointFabiano Fidêncio2015-08-171-2/+2
| | | | | | | | Coverity says: Result is not floating-point (UNINTENDED_INTEGER_DIVISION) interger_division: Dividing integer expressions "preferred->width * 100" and "zoom", and then converting the integer quotient to type double. Any remainder, or fractional part of the quotient, is ignored.
* display: remove useless identation levelFabiano Fidêncio2015-04-221-23/+21
|
* Emit one show-hint notification when enabling a displayJonathon Jongsma2015-04-091-1/+4
| | | | | Freeze notifications before setting the show hints to prevent multiple notification signals from being emitted.
* virt-viewer-display: Use MIN_DISPLAY_WIDTH/HEIGHT instead of numbersPavel Grunt2015-04-021-4/+4
|
* Use ZOOM constants instead of numbersPavel Grunt2015-04-021-8/+8
|
* Remove 'map' handler for VirtViewerDisplayJonathon Jongsma2015-01-061-19/+4
| | | | | | | | | | | | | | | | | | | | 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.
* VirtViewerDisplay: add convenience API for getting nthJonathon Jongsma2014-09-241-0/+6
| | | | | | | g_object_get(...) can be cumbersome, so add convenience API for getting the display ID ("nth-display") property: virt_viewer_display_get_nth()
* rhbz#1111514: Fix un-shrinkable displays on windows guestsJonathon Jongsma2014-06-231-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix tiny window when resetting zoom factor in gtk2 buildJonathon Jongsma2014-06-111-1/+8
| | | | | | | | | | | | | | | 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.
* Fix tiny windows for secondary displays in gtk2 buildJonathon Jongsma2014-06-101-1/+1
| | | | | | | | | | | | | | | | | | 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
* Replace DEBUG_LOG with g_debugMarc-André Lureau2014-06-101-3/+3
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1107518
* Fix gtk2 buildJonathon Jongsma2014-04-081-13/+28
| | | | | | | 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" menuMarc-André Lureau2014-03-131-24/+1
| | | | | | | Remove "Automatically resize" menu item (always enabled for Spice display now) https://bugzilla.redhat.com/show_bug.cgi?id=1007649
* Do all display alignment in virt-viewerJonathon Jongsma2013-11-271-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid extra zoom-level property notificationsJonathon Jongsma2013-10-181-0/+4
| | | | | 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
* Define the min/max zoom levels, so all values are syncMarc-André Lureau2013-08-201-6/+6
|
* win32: fix first window un-shrinkable at startMarc-André Lureau2013-07-301-8/+26
| | | | | | 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).
* spice: if zoom-level is changed, resize guest, even in fullscreenMarc-André Lureau2013-07-301-0/+1
|
* display: add fullscreen propertyMarc-André Lureau2013-07-051-0/+31
| | | | | Now that fullscreen state is no longer global to application, we need to have the current state per display
* gtk-3: Rework window size handlingHans de Goede2013-04-231-11/+38
| | | | | | | | | | | | | | | | 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>
* virt-viewer-display: Use virt_viewer_display_queue_resize where possibleHans de Goede2013-04-231-2/+2
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Do not enable extra monitors until they are explicitely enabledMarc-André Lureau2013-03-281-0/+2
|
* display: make a function to queue the dirty display allocation trickMarc-André Lureau2013-03-251-10/+13
|
* virt-viewer-display: Document difference between nth display and monitorHans de Goede2013-03-211-2/+2
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Fix compilation with older gtk+Christophe Fergeau2013-03-201-0/+1
| | | | | gtk_widget_get_mapped is only available in gtk+ 2.20, so we need a compat definition for older releases.
* virt-viewer-display: Add monitor propertyHans de Goede2013-03-201-0/+34
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* display: only un-constrain display size once it is mappedMarc-André Lureau2012-11-271-1/+2
| | | | | | 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.
* spice: avoid rounding issues when scaling up displayMarc-André Lureau2012-10-171-2/+2
| | | | | | | | | | | | 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
* Simplify display flag handlingMarc-André Lureau2012-07-231-10/+10
|
* Add VirtViewerDisplay::selectable propertyMarc-André Lureau2012-07-231-0/+23
| | | | | | | 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).
* Add a DISABLED display hintMarc-André Lureau2012-07-231-0/+15
| | | | | | | | 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)
* Run-time check values before doing bad computationMarc-André Lureau2012-07-231-1/+5
|
* Turn display:show-hint into flags typeMarc-André Lureau2012-07-231-10/+16
|
* Fix scaling of window to avoid integer truncationDaniel P. Berrange2012-04-191-2/+3
| | | | | Use round() instead of integer truncation when scaling the window, to avoid floating point precision problems on i386
* Minor simplification/optimization of VirtViewerDisplayZeeshan Ali (Khattak)2012-04-051-9/+5
|
* Fix close of VNC displaysDaniel P. Berrange2012-04-041-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* virt-viewer-display: Use a borrowed reference to sessionHans de Goede2012-03-061-1/+1
| | | | | | | | | | | | | | 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>
* Add smartcard-{insert,remove} and release-cursor virtual methodsMarc-André Lureau2012-02-221-0/+12
|
* Do not resize guest desktop if !auto-resizeMarc-André Lureau2012-02-081-0/+16
| | | | | | | | | 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.
* Implement SPICE desktop resizing that takes account of zoom levelDaniel P. Berrange2012-02-081-0/+42
| | | | | | | | | | | | | 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
generated by cgit (git 2.34.1) at 2024-05-08 09:59:01 +0000