Re: MPS and pgtk

[Björn Bidar]

Arsen Arsenović <arsen@aarsen.me> writes:

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

The biggest issue is IMHO the GTK developers as they limit the GDK
Wayland backend to the protocols that want and not what someone behind
their horizon want.

Some feature Emacs wants like to know on which desktop a window is are
against what the GNOME people thing Wayland should be.

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

There are patches to handle disconnects in GTK4, it could be possible to
port it back.

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