2003-11-14 17:48:57 +01:00
|
|
|
/*
|
2004-06-21 15:19:32 +02:00
|
|
|
*Copyright (C) 2003-2004 Harold L Hunt II All Rights Reserved.
|
2009-02-03 16:48:04 +01:00
|
|
|
*Copyright (C) Colin Harrison 2005-2008
|
2003-11-14 17:48:57 +01:00
|
|
|
*
|
|
|
|
*Permission is hereby granted, free of charge, to any person obtaining
|
|
|
|
* a copy of this software and associated documentation files (the
|
|
|
|
*"Software"), to deal in the Software without restriction, including
|
|
|
|
*without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
*distribute, sublicense, and/or sell copies of the Software, and to
|
|
|
|
*permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
*the following conditions:
|
|
|
|
*
|
|
|
|
*The above copyright notice and this permission notice shall be
|
|
|
|
*included in all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
*THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
*EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
*MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
2004-06-21 15:19:32 +02:00
|
|
|
*NONINFRINGEMENT. IN NO EVENT SHALL HAROLD L HUNT II BE LIABLE FOR
|
2003-11-14 17:48:57 +01:00
|
|
|
*ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
|
|
|
|
*CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
|
|
|
*WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
2009-02-03 16:48:04 +01:00
|
|
|
*Except as contained in this notice, the name of the copyright holder(s)
|
|
|
|
*and author(s) shall not be used in advertising or otherwise to promote
|
|
|
|
*the sale, use or other dealings in this Software without prior written
|
|
|
|
*authorization from the copyright holder(s) and author(s).
|
2003-11-14 17:48:57 +01:00
|
|
|
*
|
|
|
|
* Authors: Harold L Hunt II
|
2009-02-03 16:48:04 +01:00
|
|
|
* Colin Harrison
|
2003-11-14 17:48:57 +01:00
|
|
|
*/
|
|
|
|
|
2018-06-30 17:15:52 +02:00
|
|
|
#define WINVER 0x0600
|
|
|
|
|
2005-07-05 00:10:43 +02:00
|
|
|
#ifdef HAVE_XWIN_CONFIG_H
|
|
|
|
#include <xwin-config.h>
|
|
|
|
#endif
|
2013-06-17 19:27:56 +02:00
|
|
|
|
2005-07-05 00:10:43 +02:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/time.h>
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
#include <limits.h>
|
2013-06-17 19:27:56 +02:00
|
|
|
|
2018-06-30 17:00:16 +02:00
|
|
|
#include <xcb/xproto.h>
|
|
|
|
#include <xcb/xcb_aux.h>
|
2013-06-20 13:50:18 +02:00
|
|
|
|
2013-06-17 19:27:56 +02:00
|
|
|
#include "internal.h"
|
|
|
|
#include "winclipboard.h"
|
2003-11-14 17:48:57 +01:00
|
|
|
|
2004-06-21 15:19:32 +02:00
|
|
|
/*
|
|
|
|
* Constants
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define WIN_POLL_TIMEOUT 1
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process X events up to specified timeout
|
|
|
|
*/
|
|
|
|
|
|
|
|
static int
|
2018-06-30 17:00:16 +02:00
|
|
|
winProcessXEventsTimeout(HWND hwnd, xcb_window_t iWindow, xcb_connection_t *conn,
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
ClipboardConversionData *data, ClipboardAtoms *atoms, int iTimeoutSec)
|
2004-06-21 15:19:32 +02:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
int iConnNumber;
|
|
|
|
struct timeval tv;
|
|
|
|
int iReturn;
|
|
|
|
|
2015-11-18 22:27:23 +01:00
|
|
|
winDebug("winProcessXEventsTimeout () - pumping X events, timeout %d seconds\n",
|
2012-07-21 15:13:37 +02:00
|
|
|
iTimeoutSec);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Get our connection number */
|
2018-06-30 17:00:16 +02:00
|
|
|
iConnNumber = xcb_get_file_descriptor(conn);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Loop for X events */
|
|
|
|
while (1) {
|
|
|
|
fd_set fdsRead;
|
2012-07-21 15:13:37 +02:00
|
|
|
long remainingTime;
|
|
|
|
|
2013-11-21 16:18:48 +01:00
|
|
|
/* Process X events */
|
2018-06-30 17:00:16 +02:00
|
|
|
iReturn = winClipboardFlushXEvents(hwnd, iWindow, conn, data, atoms);
|
2013-11-21 16:18:48 +01:00
|
|
|
|
|
|
|
winDebug("winProcessXEventsTimeout () - winClipboardFlushXEvents returned %d\n", iReturn);
|
|
|
|
|
|
|
|
if ((WIN_XEVENTS_NOTIFY_DATA == iReturn) || (WIN_XEVENTS_NOTIFY_TARGETS == iReturn) || (WIN_XEVENTS_FAILED == iReturn)) {
|
|
|
|
/* Bail out */
|
|
|
|
return iReturn;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We need to ensure that all pending requests are sent */
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_flush(conn);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Setup the file descriptor set */
|
|
|
|
FD_ZERO(&fdsRead);
|
|
|
|
FD_SET(iConnNumber, &fdsRead);
|
|
|
|
|
|
|
|
/* Adjust timeout */
|
2015-11-18 22:27:23 +01:00
|
|
|
remainingTime = iTimeoutSec * 1000;
|
2012-07-21 15:13:37 +02:00
|
|
|
tv.tv_sec = remainingTime / 1000;
|
|
|
|
tv.tv_usec = (remainingTime % 1000) * 1000;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/* Break out if no time left */
|
2012-07-21 15:13:37 +02:00
|
|
|
if (remainingTime <= 0)
|
2012-03-21 20:55:09 +01:00
|
|
|
return WIN_XEVENTS_SUCCESS;
|
|
|
|
|
|
|
|
/* Wait for an X event */
|
|
|
|
iReturn = select(iConnNumber + 1, /* Highest fds number */
|
|
|
|
&fdsRead, /* Read mask */
|
|
|
|
NULL, /* No write mask */
|
|
|
|
NULL, /* No exception mask */
|
2012-07-21 15:13:37 +02:00
|
|
|
&tv); /* Timeout */
|
2012-03-21 20:55:09 +01:00
|
|
|
if (iReturn < 0) {
|
|
|
|
ErrorF("winProcessXEventsTimeout - Call to select () failed: %d. "
|
|
|
|
"Bailing.\n", iReturn);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-11-21 16:18:48 +01:00
|
|
|
if (!FD_ISSET(iConnNumber, &fdsRead)) {
|
|
|
|
winDebug("winProcessXEventsTimeout - Spurious wake, select() returned %d\n", iReturn);
|
2012-07-21 15:13:37 +02:00
|
|
|
}
|
2004-06-21 15:19:32 +02:00
|
|
|
}
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
return WIN_XEVENTS_SUCCESS;
|
2004-06-21 15:19:32 +02:00
|
|
|
}
|
|
|
|
|
2003-11-14 17:48:57 +01:00
|
|
|
/*
|
|
|
|
* Process a given Windows message
|
|
|
|
*/
|
|
|
|
|
|
|
|
LRESULT CALLBACK
|
2012-03-21 20:55:09 +01:00
|
|
|
winClipboardWindowProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
|
2003-11-14 17:48:57 +01:00
|
|
|
{
|
2018-06-30 17:00:16 +02:00
|
|
|
static xcb_connection_t *conn;
|
|
|
|
static xcb_window_t iWindow;
|
2013-06-17 20:58:20 +02:00
|
|
|
static ClipboardAtoms *atoms;
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
static Bool fRunning;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Branch on message type */
|
|
|
|
switch (message) {
|
2003-11-14 17:48:57 +01:00
|
|
|
case WM_DESTROY:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
|
|
|
winDebug("winClipboardWindowProc - WM_DESTROY\n");
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2018-06-30 17:15:52 +02:00
|
|
|
/* Remove clipboard listener */
|
|
|
|
RemoveClipboardFormatListener(hwnd);
|
hw/xwin: Fix clipboard thread restart
It seems that the clipboard thread restart mechanism has been broken for a
while, which can be demonstrated using XDMCP with KDM (e.g. to a Kubutunu 12.04
host)
KDM kills all attached clients, including the clipboard integration client,
which restarts, but then exits on WM_QUIT.
Using PostQuitMessage() in WM_DESTROY is unhelpful, as we may not actually be
quitting the thread, if we just destroyed the window because the clipboard
thread is about to retry, because he WM_QUIT message sticks around, and is
noticed the next time we look at the window message queue and confuses us into
thinking we need to quit.
Sending a WM_DESTROY is apparently never correct anyhow, see [1]
So:
1/ Use DestroyWindow() to destroy the clipboard messaging window when cleaning
up for retry or exit in winClipboardProc (the clipboard thread main proc)
2/ Send a special WM_WM_QUIT message in winClipboardWindowDestroy() from the X
server thread when the X server is resetting.
3/ When processing that WM_WM_QUIT message in the clipboard thread, cause the
clipboard window to PostQuitMessage(), which causes the clipboard thread to
exit.
[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-02-22 00:20:00 +01:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
case WM_WM_QUIT:
|
|
|
|
{
|
|
|
|
winDebug("winClipboardWindowProc - WM_WM_QUIT\n");
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
fRunning = FALSE;
|
2012-03-21 20:55:09 +01:00
|
|
|
PostQuitMessage(0);
|
|
|
|
}
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2003-11-14 17:48:57 +01:00
|
|
|
case WM_CREATE:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
2013-06-16 23:35:22 +02:00
|
|
|
ClipboardWindowCreationParams *cwcp = (ClipboardWindowCreationParams *)((CREATESTRUCT *)lParam)->lpCreateParams;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - WM_CREATE\n");
|
|
|
|
|
2018-06-30 17:00:16 +02:00
|
|
|
conn = cwcp->pClipboardDisplay;
|
2013-06-16 23:35:22 +02:00
|
|
|
iWindow = cwcp->iClipboardWindow;
|
2013-06-17 20:58:20 +02:00
|
|
|
atoms = cwcp->atoms;
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
fRunning = TRUE;
|
2013-06-16 23:35:22 +02:00
|
|
|
|
2018-06-30 17:15:52 +02:00
|
|
|
AddClipboardFormatListener(hwnd);
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2014-10-18 18:31:57 +02:00
|
|
|
case WM_CLIPBOARDUPDATE:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_generic_error_t *error;
|
|
|
|
xcb_void_cookie_t cookie_set;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE: Enter\n");
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE: We cannot bail out when NULL == GetClipboardOwner ()
|
|
|
|
* because some applications deal with the clipboard in a manner
|
|
|
|
* that causes the clipboard owner to be NULL when they are in
|
|
|
|
* fact taking ownership. One example of this is the Win32
|
|
|
|
* native compile of emacs.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Bail when we still own the clipboard */
|
|
|
|
if (hwnd == GetClipboardOwner()) {
|
|
|
|
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
2012-03-21 20:55:09 +01:00
|
|
|
"We own the clipboard, returning.\n");
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE: Exit\n");
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
/* Bail when shutting down */
|
|
|
|
if (!fRunning)
|
|
|
|
return 0;
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/*
|
|
|
|
* Do not take ownership of the X11 selections when something
|
|
|
|
* other than CF_TEXT or CF_UNICODETEXT has been copied
|
|
|
|
* into the Win32 clipboard.
|
|
|
|
*/
|
|
|
|
if (!IsClipboardFormatAvailable(CF_TEXT)
|
|
|
|
&& !IsClipboardFormatAvailable(CF_UNICODETEXT)) {
|
|
|
|
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_get_selection_owner_cookie_t cookie_get;
|
|
|
|
xcb_get_selection_owner_reply_t *reply;
|
|
|
|
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
2012-03-21 20:55:09 +01:00
|
|
|
"Clipboard does not contain CF_TEXT nor "
|
|
|
|
"CF_UNICODETEXT.\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to make sure that the X Server has processed
|
|
|
|
* previous XSetSelectionOwner messages.
|
|
|
|
*/
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_aux_sync(conn);
|
2010-02-19 03:37:00 +01:00
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - XSync done.\n");
|
2004-06-21 15:19:32 +02:00
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Release PRIMARY selection if owned */
|
2018-06-30 17:00:16 +02:00
|
|
|
cookie_get = xcb_get_selection_owner(conn, XCB_ATOM_PRIMARY);
|
|
|
|
reply = xcb_get_selection_owner_reply(conn, cookie_get, NULL);
|
|
|
|
if (reply) {
|
|
|
|
if (reply->owner == iWindow) {
|
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
|
|
|
"PRIMARY selection is owned by us, releasing.\n");
|
|
|
|
xcb_set_selection_owner(conn, XCB_NONE, XCB_ATOM_PRIMARY, XCB_CURRENT_TIME);
|
|
|
|
}
|
|
|
|
free(reply);
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Release CLIPBOARD selection if owned */
|
2018-06-30 17:00:16 +02:00
|
|
|
cookie_get = xcb_get_selection_owner(conn, atoms->atomClipboard);
|
|
|
|
reply = xcb_get_selection_owner_reply(conn, cookie_get, NULL);
|
|
|
|
if (reply) {
|
|
|
|
if (reply->owner == iWindow) {
|
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
|
|
|
"CLIPBOARD selection is owned by us, releasing\n");
|
|
|
|
xcb_set_selection_owner(conn, XCB_NONE, atoms->atomClipboard, XCB_CURRENT_TIME);
|
|
|
|
}
|
|
|
|
free(reply);
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE: Exit\n");
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Reassert ownership of PRIMARY */
|
2018-06-30 17:00:16 +02:00
|
|
|
cookie_set = xcb_set_selection_owner_checked(conn, iWindow, XCB_ATOM_PRIMARY, XCB_CURRENT_TIME);
|
|
|
|
error = xcb_request_check(conn, cookie_set);
|
|
|
|
if (error) {
|
2018-06-30 17:15:52 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
2013-06-17 21:03:04 +02:00
|
|
|
"Could not reassert ownership of PRIMARY\n");
|
2018-06-30 17:00:16 +02:00
|
|
|
free(error);
|
|
|
|
} else {
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
2012-03-21 20:55:09 +01:00
|
|
|
"Reasserted ownership of PRIMARY\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Reassert ownership of the CLIPBOARD */
|
2018-06-30 17:00:16 +02:00
|
|
|
cookie_set = xcb_set_selection_owner_checked(conn, iWindow, atoms->atomClipboard, XCB_CURRENT_TIME);
|
|
|
|
error = xcb_request_check(conn, cookie_set);
|
|
|
|
if (error) {
|
2018-06-30 17:15:52 +02:00
|
|
|
ErrorF("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
2013-06-17 21:03:04 +02:00
|
|
|
"Could not reassert ownership of CLIPBOARD\n");
|
2018-06-30 17:00:16 +02:00
|
|
|
free(error);
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
else {
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE - "
|
2012-03-21 20:55:09 +01:00
|
|
|
"Reasserted ownership of CLIPBOARD\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush the pending SetSelectionOwner event now */
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_flush(conn);
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
2018-06-30 17:15:52 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_CLIPBOARDUPDATE: Exit\n");
|
2012-03-21 20:55:09 +01:00
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
|
|
|
case WM_DESTROYCLIPBOARD:
|
2012-03-21 20:55:09 +01:00
|
|
|
/*
|
|
|
|
* NOTE: Intentionally do nothing.
|
2018-06-30 17:15:52 +02:00
|
|
|
* Changes in the Win32 clipboard are handled by WM_CLIPBOARDUPDATE
|
2012-03-21 20:55:09 +01:00
|
|
|
* above. We only process this message to conform to the specs
|
|
|
|
* for delayed clipboard rendering in Win32. You might think
|
|
|
|
* that we need to release ownership of the X11 selections, but
|
2018-06-30 17:15:52 +02:00
|
|
|
* we do not, because a WM_CLIPBOARDUPDATE message will closely
|
2012-03-21 20:55:09 +01:00
|
|
|
* follow this message and reassert ownership of the X11
|
|
|
|
* selections, handling the issue for us.
|
|
|
|
*/
|
|
|
|
winDebug("winClipboardWindowProc - WM_DESTROYCLIPBOARD - Ignored.\n");
|
|
|
|
return 0;
|
2004-06-21 15:19:32 +02:00
|
|
|
|
|
|
|
case WM_RENDERALLFORMATS:
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_RENDERALLFORMATS - Hello.\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
WM_RENDERALLFORMATS is sent as we are shutting down, to render the
|
|
|
|
clipboard so it's contents remains available to other applications.
|
|
|
|
|
|
|
|
Unfortunately, this can't work without major changes. The server is
|
|
|
|
already waiting for us to stop, so we can't ask for the rendering of
|
|
|
|
clipboard text now.
|
|
|
|
*/
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
case WM_RENDERFORMAT:
|
2012-03-21 20:55:09 +01:00
|
|
|
{
|
|
|
|
int iReturn;
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
Bool pasted = FALSE;
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_atom_t selection;
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
ClipboardConversionData data;
|
|
|
|
int best_target = 0;
|
2012-03-21 20:55:09 +01:00
|
|
|
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_RENDERFORMAT %d - Hello.\n",
|
2015-02-06 21:22:11 +01:00
|
|
|
(int)wParam);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
selection = winClipboardGetLastOwnedSelectionAtom(atoms);
|
2018-06-30 17:00:16 +02:00
|
|
|
if (selection == XCB_NONE) {
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
ErrorF("winClipboardWindowProc - no monitored selection is owned\n");
|
|
|
|
goto fake_paste;
|
|
|
|
}
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - requesting targets for selection from owner\n");
|
|
|
|
|
|
|
|
/* Request the selection's supported conversion targets */
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_convert_selection(conn, iWindow, selection, atoms->atomTargets,
|
|
|
|
atoms->atomLocalProperty, XCB_CURRENT_TIME);
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
|
|
|
|
/* Process X events */
|
2015-11-18 22:27:23 +01:00
|
|
|
data.incr = NULL;
|
|
|
|
data.incrsize = 0;
|
|
|
|
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
iReturn = winProcessXEventsTimeout(hwnd,
|
|
|
|
iWindow,
|
2018-06-30 17:00:16 +02:00
|
|
|
conn,
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
&data,
|
|
|
|
atoms,
|
|
|
|
WIN_POLL_TIMEOUT);
|
|
|
|
|
|
|
|
if (WIN_XEVENTS_NOTIFY_TARGETS != iReturn) {
|
|
|
|
ErrorF
|
|
|
|
("winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_TARGETS\n");
|
|
|
|
goto fake_paste;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Choose the most preferred target */
|
|
|
|
{
|
|
|
|
struct target_priority
|
|
|
|
{
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_atom_t target;
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
unsigned int priority;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct target_priority target_priority_table[] =
|
|
|
|
{
|
2015-11-18 22:27:23 +01:00
|
|
|
{ atoms->atomUTF8String, 0 },
|
2018-06-30 17:00:16 +02:00
|
|
|
// { atoms->atomCompoundText, 1 }, not implemented (yet?)
|
|
|
|
{ XCB_ATOM_STRING, 2 },
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
int best_priority = INT_MAX;
|
|
|
|
|
|
|
|
int i,j;
|
|
|
|
for (i = 0 ; data.targetList[i] != 0; i++)
|
|
|
|
{
|
2017-10-27 16:11:56 +02:00
|
|
|
for (j = 0; j < ARRAY_SIZE(target_priority_table); j ++)
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
{
|
|
|
|
if ((data.targetList[i] == target_priority_table[j].target) &&
|
|
|
|
(target_priority_table[j].priority < best_priority))
|
|
|
|
{
|
|
|
|
best_target = target_priority_table[j].target;
|
|
|
|
best_priority = target_priority_table[j].priority;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
}
|
|
|
|
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
free(data.targetList);
|
|
|
|
data.targetList = 0;
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - best target is %d\n", best_target);
|
|
|
|
|
|
|
|
/* No useful targets found */
|
|
|
|
if (best_target == 0)
|
|
|
|
goto fake_paste;
|
|
|
|
|
|
|
|
winDebug("winClipboardWindowProc - requesting selection from owner\n");
|
|
|
|
|
|
|
|
/* Request the selection contents */
|
2018-06-30 17:00:16 +02:00
|
|
|
xcb_convert_selection(conn, iWindow, selection, best_target,
|
|
|
|
atoms->atomLocalProperty, XCB_CURRENT_TIME);
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
|
|
|
|
/* Process X events */
|
2012-03-21 20:55:09 +01:00
|
|
|
iReturn = winProcessXEventsTimeout(hwnd,
|
|
|
|
iWindow,
|
2018-06-30 17:00:16 +02:00
|
|
|
conn,
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
&data,
|
2013-06-17 20:58:20 +02:00
|
|
|
atoms,
|
|
|
|
WIN_POLL_TIMEOUT);
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
/*
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
* winProcessXEventsTimeout had better have seen a notify event,
|
|
|
|
* or else we are dealing with a buggy or old X11 app.
|
2012-03-21 20:55:09 +01:00
|
|
|
*/
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
if (WIN_XEVENTS_NOTIFY_DATA != iReturn) {
|
|
|
|
ErrorF
|
|
|
|
("winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_DATA\n");
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
pasted = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we couldn't get the data from the X clipboard, we
|
|
|
|
* have to paste some fake data to the Win32 clipboard to
|
|
|
|
* satisfy the requirement that we write something to it.
|
|
|
|
*/
|
|
|
|
fake_paste:
|
|
|
|
if (!pasted)
|
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Paste no data, to satisfy required call to SetClipboardData */
|
2012-07-05 23:08:38 +02:00
|
|
|
SetClipboardData(CF_UNICODETEXT, NULL);
|
2012-03-21 20:55:09 +01:00
|
|
|
SetClipboardData(CF_TEXT, NULL);
|
hw/xwin: Retrieve TARGETS to avoid unnecessary failing conversion attempts
See http://cygwin.com/ml/cygwin-xfree/2013-07/msg00016.html
It looks like the change in a9aca218f557c723e637287272819a7c17174e1e had some
unforseen consequences.
If the X11 selection contents are not convertable to COMPOUND_TEXT, UTF8_STRING
or STRING format (for example, if it is an image), after those conversion
attempts have failed, we sit in winProcessXEventsTimeout() until the timeout
expires.
It also seems that maybe gnuplot doesn't respond correctly to this sequence of
conversion requests and doesn't reply to some of them, which also causes us to
sit in winProcessXEventsTimeout() until the timeout expires.
The Windows application which has requested the clipboard contents via
GetClipboardContents() is blocked until we return from WM_RENDERFORMAT, so
sitting waiting for this timeout to expire should be avoided.
So instead, explicitly request conversion to the TARGETS target, choose
the most preferred format, and request conversion to that.
Also: if there is no owned selection, there is nothing to paste, so don't bother
trying to convert it.
v2: Fix compilation with -Werror=declaration-after-statement
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2013-09-24 17:02:37 +02:00
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
|
hw/xwin: Fix hang on shutdown when we own the clipboard.
If we are the clipboard owner when we are shutdown, we recieve a
WM_RENDERALLFORMATS, to render the clipboard, so it's contents will remain
available to other applications. Unfortunately, this is far too late to do
anything useful with, as the server is waiting for the clipboard thread to exit,
and so can't process requests to convert clipboard contents.
Change so we just do nothing on WM_RENDERALLFORMATS. (I'm not convinced that
WM_RENDERALLFORMATS has ever worked usefully, in any case).
(To make this work, I guess we would need to rearrange the way shutdown works
completely: first synchronously stop the clipboard, then stop the X server)
We also then receive a WM_DRAWCLIPBOARD, perhaps telling us that the available
clipboard formats have changed (as ones which haven't been rendered are now
removed), but the clipboard owner is now the system, not us, which we have to
arrange to ignore.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
2014-04-28 13:48:15 +02:00
|
|
|
winDebug("winClipboardWindowProc - WM_RENDERFORMAT - Returning.\n");
|
2012-03-21 20:55:09 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|
|
|
|
|
2012-03-21 20:55:09 +01:00
|
|
|
/* Let Windows perform default processing for unhandled messages */
|
|
|
|
return DefWindowProc(hwnd, message, wParam, lParam);
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process any pending Windows messages
|
|
|
|
*/
|
|
|
|
|
2013-06-20 13:50:18 +02:00
|
|
|
Bool
|
2012-03-21 20:55:09 +01:00
|
|
|
winClipboardFlushWindowsMessageQueue(HWND hwnd)
|
2003-11-14 17:48:57 +01:00
|
|
|
{
|
2012-03-21 20:55:09 +01:00
|
|
|
MSG msg;
|
|
|
|
|
|
|
|
/* Flush the messaging window queue */
|
|
|
|
/* NOTE: Do not pass the hwnd of our messaging window to PeekMessage,
|
|
|
|
* as this will filter out many non-window-specific messages that
|
|
|
|
* are sent to our thread, such as WM_QUIT.
|
|
|
|
*/
|
|
|
|
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
|
|
|
|
/* Dispatch the message if not WM_QUIT */
|
|
|
|
if (msg.message == WM_QUIT)
|
|
|
|
return FALSE;
|
|
|
|
else
|
|
|
|
DispatchMessage(&msg);
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|
2012-03-21 20:55:09 +01:00
|
|
|
|
|
|
|
return TRUE;
|
2003-11-14 17:48:57 +01:00
|
|
|
}
|