Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> So, IMHO the pgtk support may be prioritized as it is the only way we
>> support Wayland natively.
>> 
>> Not sure if there are plans or alternatives under consideration to
>> change/improve pgtk, but if igc becomes an issue for it... we may
>> rethink if we really want it looking to the future?
>
> Given the sorry state of Wayland and GTK support of what Emacs needs,
> from my POV the PGTK configuration becomes less and less relevant to
> Emacs.  I'm aware that the world moves in the opposite direction, but
> unless we get some help from Wayland/GTK developers, or,
> alternatively, find ways to work around those limitations (unlikely,
> IMNSHO), there's nothing we can do about this, and nothing we could
> gain by "rethinking".  If you care about these platforms, start
> lobbying the respective development teams to cater more for Emacs and
> its needs.

I am curious about what these are, as I am quite interested in the
further development of Wayland.  IMO, X has overstayed its welcome, as
it is flawed from the ground up, visibly (to the point where I was quite
surprised the other day when I opened an X session to find noticeable
issues handling mixed refresh rate, and flickering when windows were
changing sizes or opening/closing).

I am aware of the GTK issues of not being able to multihead or handle
disconnects, but the only Wayland one I am aware of is lack of a way to
know which frames are visible (which I don't see as a big issue.. and it
is perhaps fixable anyway).

WRT GTK, I've considered Qt (but have not seen yet whether it has the
same restrictions) and multiprocessing the UI, but have not had time to
look into those options yet.  Has anyone lese considered Qt?
-- 
Arsen Arsenović