Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 13:14:11 +0800
> 
> But after some investigation, I've come to the conclusion that no
> toolkit will be able to replace the hand-crafted Emacs X11 support,
> especially in very tricky areas such as drag-and-drop and selections.

I question the validity of such a radical conclusion.  I think it is
asking for too much, something that is not really necessary in this
case.

> For example, Qt doesn't respect kDNDStatusSendHereFlag in XDND
> drag-and-drop messages, fails to wait for XdndStatus before sending
> XdndPosition/XdndDrop, and provides no method for programs to set it on
> their drop targets.  It also doesn't support the X Direct Save protocol,
> which can't be implemented on top, since the special action required for
> it is abstracted away and not available to programs using Emacs, or the
> the Motif and OffiX drag-and-drop protocols.  All of that is tolerated
> by other programs but will lead to problems over slow network
> connections.

I think this is still better than the situation with GTK.  So yes, we
need to give up something, but if someone wants a nice toolkit
appearance and widgets that look reasonably modern (something that we
will never have in the non-toolkit build), they might just agree to
the tradeoff.  After all, no one will convince me that DND is the most
important operation in Emacs, not even that it is important.  It's a
nicety, that's all.

> And it probably won't be possible to step through a selection converter
> with Edebug, or to install our own selection converter when Qt
> misencodes COMPOUND_TEXT.

Doesn't Qt provide support for non-text selections OOTB?  If it does,
why would we need to step through the converted?

Again, we shouldn't require a perfect toolkit, we should settle for a
reasonably good one.  Because none of the alternatives is such a
perfect choice.