summaryrefslogtreecommitdiffstats
path: root/client/windows
Commit message (Collapse)AuthorAgeFilesLines
* spicec-win: add image copy-paste supportArnon Gilboa2010-11-242-69/+151
| | | | | | -currently png & bmp -using wspice libs cximage.lib & png.lib -jpg & tiff will follow
* spicec-win: ignore MSVCRT.lib in x86 buildArnon Gilboa2010-11-081-2/+3
| | | | Same as in x64 build, for using the updated wspice-0.6.3
* spicec-win: add x64 to vcproj & sln (v2)Arnon Gilboa2010-10-252-0/+242
| | | | use CEGUI for x64 as well, no need for the SUPPORT_GUI hack
* spicec-win: map title string from utf8 to utf16Arnon Gilboa2010-10-251-1/+8
| | | | Fix win client broken by the utf8 patch.
* spicec-win: add #ifndef _WIN64 for u/intptr_t typedefsArnon Gilboa2010-10-241-1/+3
|
* spicec-win: Replace Set/GetWindowLong to LongPtr for x64 competabilityArnon Gilboa2010-10-241-5/+5
|
* Remove no longer used wstring_printf functionsHans de Goede2010-10-211-14/+0
|
* client: Interpret the title control message as utf8 instead of unicode16Hans de Goede2010-10-211-1/+1
| | | | | | | 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.
* spicec: add controllerArnon Gilboa2010-10-181-0/+8
| | | | | | | | | | | 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.
* spicec: add foreign menuArnon Gilboa2010-10-181-5/+13
| | | | | | | | | 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.
* spicec-win: move named_pipe definesArnon Gilboa2010-10-172-3/+4
|
* spicec-win: fix menu id push to free_sys_menu_idArnon Gilboa2010-10-171-1/+1
|
* spice-win: handle multiple types on clipboard grab send & receiveArnon Gilboa2010-10-111-19/+36
|
* spice-win: remove clipboard_changer hackArnon Gilboa2010-10-111-9/+2
| | | | Instead of keeping a flag, we simply check wether the new owner is us or not
* spice-win: handle type VD_AGENT_CLIPBOARD_NONE in ↵Arnon Gilboa2010-10-111-1/+10
| | | | Platform::on_clipboard_notify()
* spice-win: remove windows-specific bitmap cut & paste supportArnon Gilboa2010-10-111-17/+0
| | | | will wait until png comes in
* spicec: Move setting of clipboard_owner to guest to platform codeHans de Goede2010-10-061-0/+7
| | | | | | | | | | | | | | 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.
* spicec-x11: Force processing of ownerchange event when releasing the cbHans de Goede2010-10-041-0/+1
| | | | | | | | | | | | 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.
* Keep track of clipboard ownershipHans de Goede2010-10-021-0/+13
| | | | | | | | | | | | | 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 platform clipboard handling functionsHans de Goede2010-10-021-4/+4
| | | | | | | | | | 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.
* Change VD_AGENT_CLIPBOARD_GRAB to an array of typesHans de Goede2010-10-011-5/+6
| | | | | | | 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.
* client: support clipboard/selection-owner model (v2)Arnon Gilboa2010-10-011-52/+212
| | | | | | | | | | | | | | | | | | | | | | | | | -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
* client: add clipboard supportArnon Gilboa2010-07-191-0/+90
| | | | | | | | * 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
* fix typo DisplayModeListner -> DisplayModeListenerAlon Levy2010-07-191-1/+1
|
* Disable tunnel by default on windowsAlexander Larsson2010-07-081-8/+0
|
* Make distcheck workAlexander Larsson2010-07-081-0/+39
|
* Make CEGUI optionalAlon Levy2010-07-011-2/+2
| | | | | This makes the CEGUI dependency optional and off by default. Restoring previous behaviour of exiting on disconnect if disabled.
* client: add --include "common.h" for generated marshallersYonit Halperin2010-06-292-2/+2
|
* Replace log4cpp with custom log functionAlexander Larsson2010-06-283-5/+6
| | | | | Also prints a simpler error to stderr for WARN or above so that we print something on the commandline if something go wrong.
* Make pointers 32bit in new protocol formatAlexander Larsson2010-06-231-2/+2
|
* Generate marshaller/demarshallers for old protocolAlexander Larsson2010-06-223-12/+42
|
* applying zlib compression over glz on WAN connectionYonit Halperin2010-06-211-2/+10
|
* Make opengl optional, disabled by defaultAlexander Larsson2010-06-211-8/+0
| | | | | | | | | | The OpenGL renderer isn't really useful right now, its not quite up to date, its not really faster than software and it only supports a limited subset of drivers. So, lets disable it for now. Long term opengl rendering of the 2d part of spice is important if we want to combine 2d and 3d rendering (say if spice adds opengl support in the protocol). But until then this is isn't useful for normal use.
* Make generated marshallers build on win32Alexander Larsson2010-06-182-8/+23
|
* Generate demarshalling code on win32 tooAlexander Larsson2010-06-181-13/+50
|
* Client: Use the autogenerated demarshallersAlexander Larsson2010-06-181-2/+2
| | | | | | | | | | | | | | | | When a message has been read from the network we now pass it into the generated demarshaller for the channel. The demarshaller converts the network data to in-memory structures that is passed on to the spice internals. Additionally it also: * Converts endianness * Validates sizes of message and any pointers in it * Localizes offsets (converts them to pointers) * Checks for zero offsets in messages where they are not supported Some of this was previously done using custom code in the client, this is now removed.
* JPEG support: introducing jpeg encoding for spice bitmapsYonit Halperin2010-06-091-0/+8
|
* Remove all mentions of "cairo" from the codeAlexander Larsson2010-05-032-10/+10
| | | | | The command line option is renamed from "cairo" to "sw", and similarly all filenames and types from Cairo to Sw (and similar).
* client: Report window format right for win32Alexander Larsson2010-04-292-4/+14
|
* client: Support 16bpp pixmaps on win32Alexander Larsson2010-04-292-6/+33
|
* Fix up win32 client with recent changesAlexander Larsson2010-04-232-1/+10
|
* Client: Support pixmap format conversion in copy_pixelsAlexander Larsson2010-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | In order to be able to support 16bit canvases on 32bit screens and 32bit canvases on 16bit screens we need to handle format conversion when drawing RedPixmaps. The way this works now for X11 is that we only have one PIXELS_SOURCE_TYPE for pixmaps, which always has a pixman_image_t for the data, but additionally it has an XImage (shared mem or not) if the screen the pixmap was created for (i.e. an explicit one or the default screen) has the same format as the pixmap. When we draw a pixmap on a drawable we have two variants. If the pixmap has a XImage and it matches the format of the target drawable then we just X(Shm)PutImage it to the drawable. If the formats differ, then we create a temporary XImage and convert into that before drawing it to the screen. Right now this is a bit inefficient, because we always allocate a new temporary image when converting. We want to add some caching here, but at least this lets things work again.
* Move RedPixmap::Format to RedDrawable::FormatAlexander Larsson2010-04-233-9/+9
| | | | | | | | We need to know the format for other drawables too (like for instance the native format of a window), so we're pushing this down. This changes a bunch of references to be RedDrawable::, but not all. The the old RedPixmap:: references still work, but will be phased out.
* Make client canvas and pixmaps handle more formats and simplifyAlexander Larsson2010-04-233-29/+20
| | | | | | | | | | | We now support 16bit format pixmaps as well as the old ones. Including both 555 and 565 modes. We drop the palette argument for pixmap construction as it was only used for black/white anyway. Canvas creation is simplified so that there is no separate set_mode state. Canvases are already created in the right mode and never change.
* Add emacs modelines to more filesAlexander Larsson2010-04-232-0/+2
|
* Relicense everything from GPL to LGPL 2.1+Alexander Larsson2010-04-1323-207/+207
|
* Use upstream name for pthreads lib and new freetype versionAlexander Larsson2010-04-121-2/+2
|
* spice: win32 client: fix gdi lockingIzik Eidus2010-04-094-11/+11
| | | | | | | | | | | While the fix could have been more effective, it seems like this patch stream better with the coding logic that was there..., maybe later we will want to change the locking into more effective way. (There is just the primary surface to protect in reiality) Signed-off-by: Izik Eidus <ieidus@redhat.com>
* Use libjpeg to decode mjpegs, not ffmpegAlexander Larsson2010-04-081-4/+12
| | | | | | | | | | | | | | | | | | This is pretty straightforward, although there are two weird issues. The current encoder has two bugs in the yuv conversion. First of all it switches red and blue, due to something of an endianness issue. We keep this behavior by switching red and blue. Maybe we want to change this in the new protocol version since switching this may cause jpeg compression to be worse. Secondly, the old coder/decoder did rgb to/from yuv420 wrongly for jpeg, not using the "full scale" version of Y that is used in jpeg, but the other one where y goes from 16 to 235. (See jpeg/jfif reference on http://en.wikipedia.org/wiki/YCbCr for details.) The new decoder uses the full range in order to get better quality, which means old encoders will show slightly darker images. This completely removes all ffmpeg usage in the client
* Update project file to visual studio 2008Alexander Larsson2010-04-082-9/+8
|
generated by cgit (git 2.34.1) at 2024-05-30 05:38:38 +0000