On Sep 7, 2016, at 10:48 AM, Alexandre Julliard julliard@winehq.org wrote:
Module: wine Branch: master Commit: 761d244970dd189b1a639121e668a5089fd0112d URL: http://source.winehq.org/git/wine.git/?a=commit;h=761d244970dd189b1a639121e6...
Author: Alexandre Julliard julliard@winehq.org Date: Wed Sep 7 11:35:14 2016 +0900
winex11: Remove support for synthesizing clipboard formats.
Signed-off-by: Alexandre Julliard julliard@winehq.org
dlls/winex11.drv/clipboard.c | 454 ++------------------------------------ dlls/winex11.drv/winex11.drv.spec | 1 - 2 files changed, 14 insertions(+), 441 deletions(-)
Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=761d244970dd189b1a6391...
Either I'm missing something or this isn't correct.
You've made user32 synthesize formats when a Windows app puts one text format on the clipboard but not the others, but you haven't handled the case were an external program has put some text on the clipboard. For example, if some non-Wine X client puts UTF8_STRING but not STRING or text/plain on the clipboard, a Windows program will see CF_UNICODETEXT, but not CF_TEXT or CF_OEMTEXT. That shouldn't be possible.
-Ken
Ken Thomases ken@codeweavers.com writes:
On Sep 7, 2016, at 10:48 AM, Alexandre Julliard julliard@winehq.org wrote:
dlls/winex11.drv/clipboard.c | 454 ++------------------------------------ dlls/winex11.drv/winex11.drv.spec | 1 - 2 files changed, 14 insertions(+), 441 deletions(-)
Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=761d244970dd189b1a6391...
Either I'm missing something or this isn't correct.
You've made user32 synthesize formats when a Windows app puts one text format on the clipboard but not the others, but you haven't handled the case were an external program has put some text on the clipboard. For example, if some non-Wine X client puts UTF8_STRING but not STRING or text/plain on the clipboard, a Windows program will see CF_UNICODETEXT, but not CF_TEXT or CF_OEMTEXT. That shouldn't be possible.
The plan is that the driver will be modified to go through the Windows API. So if some X client puts text on the clipboard, the X11 driver will do a SetClipboardData(CF_UNICODETEXT), and user32 will then synthesize the others.
On Sep 8, 2016, at 7:55 PM, Alexandre Julliard julliard@winehq.org wrote:
Ken Thomases ken@codeweavers.com writes:
On Sep 7, 2016, at 10:48 AM, Alexandre Julliard julliard@winehq.org wrote:
dlls/winex11.drv/clipboard.c | 454 ++------------------------------------ dlls/winex11.drv/winex11.drv.spec | 1 - 2 files changed, 14 insertions(+), 441 deletions(-)
Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=761d244970dd189b1a6391...
Either I'm missing something or this isn't correct.
You've made user32 synthesize formats when a Windows app puts one text format on the clipboard but not the others, but you haven't handled the case were an external program has put some text on the clipboard. For example, if some non-Wine X client puts UTF8_STRING but not STRING or text/plain on the clipboard, a Windows program will see CF_UNICODETEXT, but not CF_TEXT or CF_OEMTEXT. That shouldn't be possible.
The plan is that the driver will be modified to go through the Windows API. So if some X client puts text on the clipboard, the X11 driver will do a SetClipboardData(CF_UNICODETEXT), and user32 will then synthesize the others.
I'm not sure that's feasible. The Mac pasteboard doesn't provide notification of when other apps change it. If you own the pasteboard, you can be notified when some other app takes ownership and you lose it, but that's it.
What is the plan with respect to replacing the synthesized content? As user32 currently stands, GetClipboardData() can call render_synthesized_format() which calls SetClipboardData(). After that, how do you distinguish between CF_TEXT synthesized from CF_UNICODETEXT and app-provided CF_TEXT? If an app does SetClipboardData(CF_UNICODETEXT, L"string one"), then GetClipboardData(CF_TEXT) gives "string one", then the app calls SetClipboardData(CF_UNICODETEXT, L"string two"), but GetClipboardData(CF_TEXT) still gives "string one". The same applies if it's the X11 driver making the calls to SetClipboardData() due to the X selection owner setting new data.
Will the X11 driver clear the clipboard on each update by the other X client? If so, will Wine be stealing selection ownership from the other X client each time it changes? Given multiple Wine processes, will they be competing for it?
The way I envisioned this was that synthesis would be entirely a query-time phenomenon, perhaps with some caching within user32. So, CountClipboardFormats(), EnumClipboardFormats(), IsClipboardFormatAvailable(), and GetClipboardData() would call into the driver and get a list of the real formats. User32 would then add in any missing formats that are synthesized from those real formats and include them in the count/enumeration/availability check. And, of course, GetClipboardData() would actually synthesize the data, as necessary. None of this would be "stored" on the clipboard in the sense of SetClipboardData(). The drivers would not be informed of the synthesized formats or data.
-Ken
On Sep 8, 2016, at 10:37 PM, Ken Thomases ken@codeweavers.com wrote:
What is the plan with respect to replacing the synthesized content? As user32 currently stands, GetClipboardData() can call render_synthesized_format() which calls SetClipboardData(). After that, how do you distinguish between CF_TEXT synthesized from CF_UNICODETEXT and app-provided CF_TEXT? If an app does SetClipboardData(CF_UNICODETEXT, L"string one"), then GetClipboardData(CF_TEXT) gives "string one", then the app calls SetClipboardData(CF_UNICODETEXT, L"string two"), but GetClipboardData(CF_TEXT) still gives "string one".
Hmm. Actually, to my surprise, this is exactly how Windows behaves. I guess the synthesized format is fixed on the first GetClipboardData() and is not re-synthesized even if the source format is changed.
-Ken
Ken Thomases ken@codeweavers.com writes:
What is the plan with respect to replacing the synthesized content? As user32 currently stands, GetClipboardData() can call render_synthesized_format() which calls SetClipboardData(). After that, how do you distinguish between CF_TEXT synthesized from CF_UNICODETEXT and app-provided CF_TEXT? If an app does SetClipboardData(CF_UNICODETEXT, L"string one"), then GetClipboardData(CF_TEXT) gives "string one", then the app calls SetClipboardData(CF_UNICODETEXT, L"string two"), but GetClipboardData(CF_TEXT) still gives "string one". The same applies if it's the X11 driver making the calls to SetClipboardData() due to the X selection owner setting new data.
Will the X11 driver clear the clipboard on each update by the other X client? If so, will Wine be stealing selection ownership from the other X client each time it changes? Given multiple Wine processes, will they be competing for it?
Probably the X11 driver will request the data lazily, but yes, it would clear the clipboard when the selection changed, and assert ownership in the Win32 sense. That doesn't imply it will be stealing X11 selection ownership. It will only do that when it's the app that empties the clipboard, not the driver itself.
Ken Thomases ken@codeweavers.com writes:
The way I envisioned this was that synthesis would be entirely a query-time phenomenon, perhaps with some caching within user32. So, CountClipboardFormats(), EnumClipboardFormats(), IsClipboardFormatAvailable(), and GetClipboardData() would call into the driver and get a list of the real formats. User32 would then add in any missing formats that are synthesized from those real formats and include them in the count/enumeration/availability check. And, of course, GetClipboardData() would actually synthesize the data, as necessary. None of this would be "stored" on the clipboard in the sense of SetClipboardData(). The drivers would not be informed of the synthesized formats or data.
Going beyond synthesized formats, the high-level vision is that there will be a fully functional clipboard implementation in user32, that should pass all the tests and allow copy/paste between apps inside the same prefix, even with no driver implementation at all.
Once this is working, I believe it will be possible to reimplement the driver side using only the exported Win32 clipboard APIs. I admit that I haven't finished that part yet, so there may turn out to be a need for some private hooks, but I'm hoping we can do without.
Once this is working, I believe it will be possible to reimplement the driver side using only the exported Win32 clipboard APIs. I admit that I haven't finished that part yet, so there may turn out to be a need for some private hooks, but I'm hoping we can do without.
I think we will at least need some sort of hook in OpenClipboard, so that the driver can poll the host clipboard if it needs to.
The driver will also have to ensure that multiple processes don't compete for clipboard ownership when a non-Wine application holds the host clipboard. It probably has to be done in the explorer process. Otherwise, we'd have lifetime issues as well - any other process might be killed before the clipboard changes.
There are still problems to be solved, but I like the direction this is taking.
-
Alexandre Julliard -
Ken Thomases -
Vincent Povirk