Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

[Ken Thomases]

On Sep 8, 2016, at 7:55 PM, Alexandre Julliard <julliard at winehq.org> wrote:
> 
> Ken Thomases <ken at codeweavers.com> writes:
> 
>> On Sep 7, 2016, at 10:48 AM, Alexandre Julliard <julliard at 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=761d244970dd189b1a639121e668a5089fd0112d
>> 
>> 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