GNOME Bugzilla – Bug 706609
win32: use AddClipboardFormatListener when available
Last modified: 2018-05-02 15:46:22 UTC
Clipboard viewer method has design issues, they can be easily broken by misbehaving applications. AddClipboardFormatListener is the recommended method, although it was added only since Vista.
Created attachment 252791 [details] [review] win32: use AddClipboardFormatListener when available
Just checked your commit from bug 6552239 including comment https://bugzilla.gnome.org/show_bug.cgi?id=652239#c6 but unfortunately I still don't get it. That one was adding SetClipboardViewer() with the comment: """This is a rewrite of e6fa7394baa8a7cb80ae01a0c81729717019172b, with misc fixes that should help with some bugs Tim was talking about.""" but without any description of the problem it was supposed to solve. Now you want to add AddClipboardFormatListener() but still keep the IMO questionable clipboard viewer code as a fallback? Wouldn't it be better to revert commit 88707e6912c376faedf0b8c5b02895aa18473cb4 and just return FALSE from gdk_display_supports_selection_notification() if AddClipboardFormatListener() is not available?
(In reply to comment #2) > Just checked your commit from bug 6552239 including comment > https://bugzilla.gnome.org/show_bug.cgi?id=652239#c6 but unfortunately I still > don't get it. That one was adding SetClipboardViewer() with the comment: > > """This is a rewrite of e6fa7394baa8a7cb80ae01a0c81729717019172b, with > misc fixes that should help with some bugs Tim was talking about.""" The title of the bug/patch was "resurect Windows clipboard selection notification". I already replied in that bug to you what it is for. > but without any description of the problem it was supposed to solve. Now you > want to add AddClipboardFormatListener() but still keep the IMO questionable > clipboard viewer code as a fallback? Yes, because AddClipboardFormatListener() is only Vista+ and we still want to support XP. > Wouldn't it be better to revert commit 88707e6912c376faedf0b8c5b02895aa18473cb4 > and just return FALSE from gdk_display_supports_selection_notification() if > AddClipboardFormatListener() is not available? No, for the reasons above.
Apparently I did not make myself clear: your answer is just iterating information already available. I'm asking for a real world example to reproduce the problem you were trying to solve. I reverted your patch locally the first time I have seen a crash related with the clipboard viewer chain and did not miss anything afterwards. Tested the clipboard functionality from Dia (with multiple formats, direct and with delayed rendering) to Office and also to GIMP and Inkscape running on windows. But as I said: I do not understand the use case you want to fulfill so maybe my tests did not cover it.
(In reply to comment #4) > Apparently I did not make myself clear: your answer is just iterating > information already available. I'm asking for a real world example to reproduce > the problem you were trying to solve. > I reverted your patch locally the first time I have seen a crash related with > the clipboard viewer chain and did not miss anything afterwards. Tested the > clipboard functionality from Dia (with multiple formats, direct and with > delayed rendering) to Office and also to GIMP and Inkscape running on windows. > But as I said: I do not understand the use case you want to fulfill so maybe my > tests did not cover it. If you have a crash related to clipboard viewer chain, please report a bug. A clipboard listener is required to implement: - a "paste" state UI enabled/disabled when the clipboard has data (menu/button etc), without having to query or poll. - a "viewer": an application that shows you the content of the clipboard. - a remote desktop application that must take/inform of clipboard ownership on the remote side (ie, my case)
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
still relevant
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/442.