Application::set_hotkeys can throw an exception if it fails parsing
the string describing the hotkeys to set. Currently this exception
is uncaught which causes spicec to terminate when the controller
tries to set invalid hotkeys. Fall back to using the default
hotkeys when the controller sends an invalid hotkeys string.
The default stays the same -- false.
A race could prevent setting ForeignMenu::_active correctly.
That happened when Application::on_app_activated was called before
_foriegn_menu was created. When foriegn_menu was created its
_active defaults to false, and that has not changed, until focus
was taken out and back in spice-client window.
This caused usbrdr to sometimes not auto-share devices, unless
the user switched focus to a different application and back to
spicec.
The fix updates ForiegnMenu::_active upon creation.
The endless recursion happens due to Application::prepare_monitors calling RedScreen::resize
calling Application::rearrange_monitors calling Application::prepare_monitors
I changed RedScreen::resize not to call rearrange_monitors. Instead,
the monitor should be configured correctly from Application, before
calling resize.
In addition, I made some cleanups to allow reusing rearrange_monitors code.
Having a loglevel variable is much more useful if we can actually change
its value without a recompile. Use a SPICEC_LOG_LEVEL environment variable so
we can do this from the spice xpi / activex too (by setting the environment
variable before starting the browser).
In commit 44073d1b38 - client: improve WAN option description
one "," was missing at the end of the line. Since the next argument
was a string too, gcc silently concatenated them, and thanks to C++
polymorphic functions, the compiler didn't complain about the
missing argument, so it went unnoticed.
The effects are pretty bad though, since it prevents spicec from
running because it thinks command line parsing fails.
The WAN options (--color-depth and --disable-effects) need
support from the guest agent to be working. Currently they are
only supported on Windows. While I don't want to explicitly
mention Windows in --help output, we can hint that it won't
work with all guests in --help. This fixes RH bug #712941
After shift+F11, both in Windows 7 and xp clients, WM_KEYUP events were missing for
SHIFT and F11. For F11 it was less important since unpress_all was preformed for all keys.
However, we perform sync for all the keyboard modifiers and the GetKeyboardState returns "down" for shift.
In windows7 client, we sometimes received afterwards a F11 KEYDOWN event repetition, and this caused SHIFT+F11 to be called again.
Not performing hiding of the windows while changing client resolutions, solved the problem of missing events, and I don't see any difference
in how spice looks while toggling to full screen.
Using GetAsyncKeyState, returns "UP" for shift in windows 7, and helps avoid performing shift+f11 again, if there is an F11 repetition
before we receive the KEYUP event for shift.
Fixed since v1:
- don't include C code, rather use the common lib
- add missing spice_openssl_verify_free() call
- keep the extra-parsing of subject for error reporting
When using config.h, it must be the very first include in all source
files since it contains #define that may change the compilation process
(eg libc structure layout changes when it's used to enable large file
support on 32 bit x86 archs). This commit adds it at the beginning
of all .c and .cpp files
spice client and spice server shares code from
common/{gdi,gl,sw}_canvas.[ch]. However, while most of the code is
shared, the server code wants a canvas compiled with
SW_CANVAS_IMAGE_CACHE defined while the client code wants a canvas
compiled with SW_CANVAS_CACHE.
The initial autotools refactoring didn't take that into account,
this is now fixed by this commit. After this commit, the canvas
files from common/ are no longer compiled as part of the
libspice-common.la convenience library. Instead, there are "proxy"
canvas source files in client/ and server/ which #include the
appropriate C files after defining the relevant #define for the
binary that is being built.
To prevent misuse of the canvas c files and headers in common/,
SPICE_CANVAS_INTERNAL must be set when including the canvas headers
from common/ or when building the c files from common/ otherwise
the build will error out.
This fixes fdo bug #32896:
"Subject in certificates is stored in following format (values separated by
comma and space):
grep Subject: server-cert.pem | awk -F": " '{print $2}'
O=REDHAT, CN=10.34.58.2
While spicec expects that values in host subject are separated only by comma:
spicec --host-subject "O=REDHAT,CN=10.34.58.2"
"
In this case, ignoring spaces make it much easier to directly copy and paste
the subject line from certificates.
In some cases rhev-m changes the hotkey for releasing the mouse grab
to ctrl + alt. This makes it impossible to send ctrl + alt + other-key
to the guest, even when using sticky alt.
What happens is:
-press alt until sticky alt activates
-release alt (but recorded state stays pressed due to sticky alt)
-press ctrl
-hotkey code sees ctrl+alt pressed, releases mouse grab
-mouse grab release code does an unpress all -> end of sticky state.
This patch makes it possible to atleast send ctrl + alt + del (or other key)
using sticky alt. Note: even with this patch it is still a bad idea to
use ctrl + alt as hotkey combi.
separate initialization into before command line parsing and after,
call later only if command line parsing succeeds (in particular, it
"fails" if --help is given).
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.
Currently when going / starting fullscreen if the guest resolution for one of
the monitors is higher then that monitor on the client can handle, we show a
white screen. Leaving the user stuck (unless they know the fullscreen key
switch combi) with a white screen when starting the client fullscreen from
the XPI.
This patch changes the client to fall back to windowed mode in this case
instead.
Currently when compiled with the gui enabled if you specify a host to connect
to on the cmdline the gui flashes by (show_gui gets called, then the connect
handler calls hide_gui as soon as the connection is made).
This patch removes this ugly flashing by of the gui.
Currently we are calling show_info_layer from hide_gui in application.cpp, but
there are 2 cases where this does not happen:
1) When compiled without gui support hide_gui is a complete nop, so we never
show the info layer when compiled without gui support
2) When run with --controller we never show the gui, and hide_gui
checks if there is a gui to hide as the first thing and if not returns
resulting in show_info_layer not being called, and thus the info layer
not showing when launched from the xpi
This patch fixes both by adding a call to show_info_layer from
on_visibility_start note that on_visibility_start also calls hide_gui,
so in some cases show_info_layer may be called twice, this is not a
problem as show_info_layer is protected against this.
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.
Now that Application::hide_me actually does what the name suggests
(hide the entire client, ie all client windows), the gui using it to
not show the gui layer leads to the entire client disappearing when
one presses close in the GUI or dismisses a GUI dialog. This patch makes
the GUI code call hide_gui instead of hide_me, fixing this.
1) Make the order when starting up in fullscreen mode the same as when
switching from window -> fullscreen:
First set the mode, then make the window fullscreen
2) Change the order when leaving fullscreen mode, first restore the original
monitor mode, then make the window non fullscreen. Changing the monitor
mode in X11 causes the window manager to re-arrange windows, and if this
happens while compiz is busy mapping the window it gets confused and
maps the window with a maxmimized size.
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.
-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
