Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 20:34:39 +0800
> 
> > 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.

And my point is that from where I stand, the above is not an absolute,
drop-dead requirement.  Given the magnitude of the problems and the
importance of reasonably good solutions, we should be pragmatic in
this, not dogmatic.

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

If that's your problem, I have no problem: COMPOUND_TEXT is a niche
capability that I'm surprised people still need these days.