client/ contains several .cpp file which only #include a .c file
of the same name. This is unusual and seems to only be done to
get C++ name mangling on the symbols defined in the C file.
Now that all headers files in common/ use extern "C", these
wrappers are no longer useful.
using updated windows libraries:
http://www.spice-space.org/download/stable/wspice-x86_08032011.ziphttp://www.spice-space.org/download/stable/wspice-x64_08032011.zip
-remove IgnoreDefaultLibraryNames="MSVCRT.lib", since pixman is now compiled
using MT threading model similar to other libraries. It used to be mistakenly
compiled with MD.
-downgrade freetype lib to 2.3.11-7, which is the one used/tested with
CEGUI 0.6.2
-pthread lib patched (InterlockedCompareExchange), so x64 client will no
longer crash on SelectClipRgn, BitBlt etc.
instead of ..\..\..\spice-protocol. Relative path to another git tree is a bit
ugly, since it requires spice-protocol to be in a specific location.
SPICE_PROTOCOL_DIR should also be used in windows qxl and vdagent instead of
SPICE_COMMON_DIR, which is an old and confusing name, due to the common
directory in spice git repo.
This patch stops us from drawing the spice client watermark at the top of
the virtual machine view. We have had requests through several channels to
remove this as it has little added value, and is seen as annoying by some.
Given that we now also have a bugzilla for this I think it is time we really
remove it.
The activex browser plugin is sending unicode16 text, where as the
xpi one is sending utf8 text. After discussing this on irc we've decided
that utf8 is what we want to use. So the client (this patch), and the
activex will be changed to expect resp. send utf8 text as the title.
Spice client controller enables external control (e.g., by XPI or ActiveX) of
the client functionality.
The controller protocol enables setting parameters (host, port, sport, pwd,
secure channels, disabled channels, title, menus, hotkeys etc.), connecting
the server, showing and hiding the client etc.
The controller is based on the cross-platform named pipe.
Spice foreign menu enables external control of the client menu.
The foreignmenu protocol enables an external application to:
add a submenu, set its title, clear it, add/modify/remove an item etc.
Foreign menu is based on the cross-platform named pipe.
Atleast under x11 there is a race condition when setting the clipboard
owner to guest from the RedClient code rather then doing it in Platform.
After the XSetSelectionOwner() in Platform::on_clipboard_grab(), which runs
from the main message loop thread, the x11 event thread can receive a
SelectionRequest event from another x11 app, before the RedClient code
has set the clipboard owner, which will trigger the owner != guest
check in the SelectionRequest event handling code.
By moving the setting of the owner in to Platform::on_clipboard_grab() it
gets protected by the clipboard lock, which closes this tiny race.
Make sure we process the XFixesSetSelectionOwnerNotify event caused by
us setting the clipboard owner to none, directly after setting the owner
to none. Otherwise we may end up changing the clipboard owner to none, after
it has already been re-owned because the XFixesSetSelectionOwnerNotify event
to owner none is event is still pending when we set the new owner, and
then changes the owner back to none once processed messing up our clipboard
ownership state tracking.
I saw this happening when doing copy twice in succession inside the guest.
Given that all clipboard handling is async, it is possible to for
example receive a request for clipboard data from the agent
while the client no longer owns the clipboard (ie a
VD_AGENT_CLIPBOARD_RELEASE message is in transit to the agent).
Thus it is necessary to keep track of our notion of clipboard ownership
and check received clipboard messages (both from other apps on the client
machine and from the agent) to see if they match our notion and if not
drop, or in case were a counter message is expected nack the clipboard
message.
Rename the 4 platform clipboard functions which get called
upon receival of an agent clipboard message to on_clipboard_*
The old set_clipboard_* names were confusing as they suggest being
a class property setter (like set_event_listener) rather then
event handler, and set_clipboard_owner was causing a name conflict
with the next patch in this series.
A clipboard owner can indicate that it can supply the data the clipboard
owns in multiple formats, so make the data passed with a
VD_AGENT_CLIPBOARD_GRAB message an array of types rather then a single
type.
-includes most of Hans' review fixes (up to the SelectionRequest comment [4]) & X11 wips sent by Hans (10x!)
-use the VD_AGENT_CLIPBOARD_* types in the platform code
-add ifs for VD_AGENT_CAP_CLIPBOARD_BY_DEMAND in both sides
-support the GRAB/REQUEST/DATA/RELEASE verbs in both ways
-pasting clipboard data is now "only-by-demand" from both sides (client and agent), whose behavior is symmetric
-client and agent don't read or send the contents of the clipboard unnecessarily (e.g. copy, internal paste, repeating paste, focus change)
-set client as clipboard listener instead of application
-add atexit(cleanup) in win platform
linux:
-instead of clipboard atom selection instead of XA_PRIMARY
-enable USE_XRANDR_1_2 and support clipboard in MultyMonScreen
-send utf8 with no null termination, remove ++size
-add xfixes in configure.ac & Makefile.am
windows:
-bonus: support image cut & paste, currently only on windows
not done yet:
-clipboards formats are still uint32_t, not mime types stores as strings
-platform_win is still used, not the root window
-not replaced the ugly windows CF_DIB in agent/winclient
* windows - untested
* linux - small strings both ways, large implemented differently:
* client to guest - support INCR
* guest to client - we supply a single possibly very large property
* requires server changes in next patch to work with spice-vmc
