| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add spice-glib support for gl scanout messages.
A note about SpiceGlScanout: it is struct with scanout details,
registered as a boxed type, with associated gl-scanout property. That
way, it doesn't need a seperate signal for change notification and the
current scanout can be retrieve with gobject getter. Since boxed
property are always duplicated by g_object_get(), an additional
spice_display_get_gl_scanout() method returns the current scanout
without duplication (that's what spice-gtk display widget will use).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were several shortcomings to the existing file transfer API,
particularly in terms of monitoring ongoing file transfers. The major
issue is that spice_main_file_copy_async() allows you to pass an array
of files, but the progress callback does not provide a way to
identify which file the callback is associated with. This makes it
nearly impossible for an application to monitor file transfers.
In addition, the SpiceDisplay widget automatically handles drag-and-drop
actions on the widget, and initiates file transfers without allowing the
application to specify a progress callback. So there's no way for an app
to monitor file transfers that are initiated via drag and drop.
http://lists.freedesktop.org/archives/spice-devel/2015-September/021931.html
has a more detailed explanation of the issues.
This change doesn't break the existing API, but adds some new API that
will allow an application to monitor file transfer progress, even for
transfers that are initiated within spice-gtk itself.
- A new public SpiceFileTransferTask object is added.
- The SpiceMainChannel object gains a "new-file-transfer" signal that is
emitted whenever a new file transfer is initiated. The
SpiceFileTransferTask object is passed to the signal handler.
- The application can retain this object and monitor its 'progress'
property to be notified when the progress of the file transfer
changes. The SpiceFileTransferTask::finished signal indicates when the
given file transfer has completed. The application can also cancel the
file transfer by calling the _cancel() method.
The 'spicy' test application has been updated to use this new API and
display a simple dialog showing the progress of individual files.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new function that allows the caller to decide whether to send
the new status down to the server or not (analogous to the difference
between spice_main_set_display() vs spice_man_update_display()).
This new function is needed to reduce unnecessary MonitorsConfig
messages from being sent to the server. Because spice-gtk does not
maintain any display state internally, it depends on the application to
maintain that state. Some state changes come from the server itself
(e.g. the guest has changed resolution due to some activity within the
guest), and some come from the application (e.g. the user has resized
the window of the client). Changes that come from server updates do not
need to be sent back down to the server, whereas those that originate
from the application *do* need to be sent to the server.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See spice-common for protocol details. phodav, a webdav server library,
is imported thanks to a submodule, until this project has a stable API
and releases.
The webdav channel is reponsible for handling port events and
multiplexing the request streams. Extra care has been made to avoid
blocking and to enable some fairness between concurrent streams, however
this has been particularly tricky and is likely to have some issues
left.
The webdav server is run in a seperate thread, using libsoup. The client
communication is done via a local tcp socket, but protected to only
accept local connection and with a pretty strong password.
The home directory is exported for the remote to browse, which seems to
be a sensible default atm.
|
| | |
|
| |
|
|
|
| |
Learn to return the currently configured proxy, to allow
client to tweak parameters, such as username and password.
|
| |
|
|
|
| |
Add a function to retrieve the last GError from a channel, this may be
useful to provide additional error details to the client.
|
| |
|
|
|
| |
Generalize a little bit SpiceProxy to allow easy URI manipulation by
clients.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit a285e0187d15ad650f6524f3811072fa55b20617.
This API was not actually needed for what I intended to use it for. So revert
for now. We can always add it back if necessary in the future.
Conflicts:
gtk/spice-widget.c
|
| |
|
|
|
| |
Add spice_display_get_monitor_config() to get the current configuration of the
display.
|
| |
|
|
|
|
|
| |
And document both spice_channel_string_to_type and
spice_channel_type_to_string.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| | |
|
| |
|
|
|
|
| |
(fdo#63807)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A Spice port channel carry arbitrary data between the Spice client and
the Spice server. It may be used to provide additional services on top
of a Spice connection. For example, a channel can be associated with
the qemu monitor for the client to interact with it, just like any
qemu chardev. Or it may be used with various protocols, such as the
Spice Controller.
A port kind is identified simply by a fqdn, such as org.qemu.monitor,
org.spice.spicy.test or org.ovirt.controller...
|
| |
|
|
|
| |
Add spice_channel_flush_async() that asynchronously will write all the
pending channel data.
|
| |
|
|
|
|
|
|
|
| |
If the server is capable of SPICE_INPUTS_CAP_SCANCODE, then we send
can send a single message with key press and release, to avoid
unwanted guest side key repeatition due to network jitter.
If the server is not capable, spice-gtk will use some compatibility
mode and send the existing DOWN and UP key events seperately.
|
| | |
|
| |
|
|
| |
Fix all the unused symbols and a few warnings (a lot left)
|
| |
|
|
|
| |
Add an agent capability check before calling those functions from
gtk-session. Avoid extra warnings.
|
| |
|
|
|
|
|
|
|
| |
This patch adds a SpiceUsbDeviceWidget which apps can use to easily
add an UI to select USB devices to redirect (or unredirect).
See spicy for an example usage.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since usb device manager keeps track of which usb channels there are and
if they have usb devices attached there should be one usb-device-manager
instance per session, rather then one global singleton.
Tying the usb-device-manager to the session also allows us to get rid of
spice_usb_device_manager_[un]register_channel and the need for SpiceDisplay
to call these.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes copy and paste with multi-monitor guests. There still is
one small issue left with this patch, changing the setting for auto-clipboard
in one spicy window, does not get reflected in the Options menu of the
other spicy windows.
This can be fixed by listening to the notify signal, this also requires
SpiceDisplay to listen to property changes on its SpiceGtkSession and
then do a g_object_set on itself to update its own property (and also
emit its own notify signal.
I'll write a separate patch for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This initial commit of the SpiceGtkSession Class only adds the empty
class and the 1:1 linkage to SpiceSession through 2 new private methods
added to SpiceSession: spice_session_{get|set}_gtk_session.
The following commits will move things which are currently per SpiceDisplay,
but which really should be global, such as the clipboard, over to
SpiceGtkSession.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
|
|
|
| |
This is just a place holder for now. A better implementation requires
gusb changes, and I hope there will be an official gusb release by the
time I get around to fixing this up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
