Re: Abysmal state of GTK build

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Well, the point I was trying to make was that we need a toolkit where we
can use the same techniques that we already do to mix Xlib code with
toolkit code, letting the toolkit draw widgets, while allowing Emacs to
handle complicated window system behavior such as drag-and-drop.

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

COMPOUND_TEXT is an X11 specific text format that Qt doesn't support
correctly out of the box.

> 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.

Indeed, but that isn't the point I was trying to make.