[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48093: 28.0.50; feature/pgtk: multiple display: clipboard
From: |
Po Lu |
Subject: |
bug#48093: 28.0.50; feature/pgtk: multiple display: clipboard |
Date: |
Sat, 02 Jul 2022 13:05:55 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) |
Rajeev N <rajeev.jnk@sivalik.com> writes:
> sorry, I will not be able to spend any cycles on this anytime soon.
Then I guess this has probably been fixed by the complete selection code
rewrite, which for the most part bypasses the buggy GTK layer.
However, there is one piece of code that still worries me:
/* GC must not happen inside this segment. */
block_input ();
gtk_selection_clear_targets (FRAME_GTK_WIDGET (f), selection_atom);
if (VECTORP (targets))
{
gtargets = xzalloc (sizeof *gtargets * ASIZE (targets));
ntargets = 0;
for (i = 0; i < ASIZE (targets); ++i)
{
if (SYMBOLP (AREF (targets, i)))
gtargets[ntargets++].target
= SSDATA (SYMBOL_NAME (AREF (targets, i)));
}
gtk_selection_add_targets (FRAME_GTK_WIDGET (f),
selection_atom, gtargets,
ntargets);
xfree (gtargets);
}
unblock_input ();
Here, the GTK API is being used to announce the selection targets, since
the corresponding GDK APIs are not public and are badly abstracted, most
of them being specific to individual GDK backends.
I tested briefly with two Wayland displays and it seems to work fine for
me, but I don't use PGTK on a daily basis and thus cannot be sure.