Re: Platform independent graphical display for Emacs

[Dmitry Gutov <dgutov@yandex.ru>]

On 25.12.2021 14:51, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> That should pretty much guarantee that it will be maintained. But the
>> odds of reaching that point are pretty slim, of course, given that we
>> don't lack in different viewpoints here.
> 
> Maintaining a toolkit, even more so one that supports as many platforms
> as we do, is not a one-person job, especially in this rapidly changing
> world.
> 
> Case in point: Wayland (which we definitely want to support.)

AFAIK, no ports other than PGTK have any Wayland support either.

So with the transition of GNU/Linux world from X to Wayland, we'd either 
have drop all other ports (aside from w32 and ns, I suppose), or end up 
dealing with this somehow anyway.

> A single expert (or even a small group of experts) will have a very hard
> time maintaining a toolkit that will work with Wayland, seeing as you
> have to understand XML, a complicated wire protocol and several very
> rapidly changing "standard" extensions to do any meaningful work with
> it.  For example, an unstable extension is required for a toplevel to
> obtain the input focus, and another is required to handle input methods.
> 
> Seeing as other programs such as Chromium (and by extension VS-Code) and
> even toolkits with ample funding and full-time developers such as Qt
> still struggle with Wayland support, I think it would be a very, very
> bad idea for us to take that task onto ourselves.

I suppose the hope at this point is that Wayland and set of its 
extensions will stabilize soon-ish, because it would also help with 
adoption by other programs.

> Besides, we will probably not be able to implement everything on other
> platforms such as NS, Haiku, or MS-Windows, so such a configuration will
> likely be specific to X, which begs the question of why we should use
> that configuration instead of the other in-tree X toolkit Lucid.

Lucid doesn't look nice, nor does it support modern features like 
scaling. But for all I know, the potential developer could start with 
improving Lucid instead, and at some point reach the state where they 
are satisfied with how things work.

After that, it might be a question whether people want to try unifying 
the w32 and ns ports too (by switching to rendering widgets with e.g. 
OpenGL). Or not.

>> I would at least hope that switching to another no-toolkit
>> configuration (and removing the current one soon after) is on the
>> table. After getting enough consensus, naturally.
> 
> You can't really switch "from one no-toolkit configuration" to another,
> because they cannot be much different by definition.
> 
> My idea of the only remotely practical way to implement a similar
> configuration is for everything on the display (such as menu bars and
> scroll bars, but not dialog boxes or popup menus) to be drawn by
> redisplay through the RIF similarly to how the tool bar is displayed at
> present in all platforms except NS and GTK.  I think we can already do
> that with the menu bar as well -- the only job that's left is to make it
> look nicer, possibly by applying a box and a gray background to the
> individual buttons there.
> 
> Ideally, this won't require significant changes to the X specific code
> at all.
> 
> However, exposing that to Lisp would be a bad idea.  If the tab bar
> feature is anything to judge by, this seems to be quite difficult and
> also tends to create obscure bugs, such as the image relief bugs with
> the tab bar.

Can't comment on that.

>> It might become feasible to remove a number of them, though. If my
>> hunch is right that people have been holding on to no-toolkit, or
>> Motif, or Lucid, because they each have some pet bug which is present
>> on newer toolkit ports, but not on their chosen one.
> 
> People might also have a preference for Lucid or Motif, or even GTK+.
> There are also people who want to use Motif/Lucid specific resources, or
> GTK stylesheets.
> 
> I hope we will not remove any of the toolkit code, no matter what.
> 
>> Having a port like that developed could get us +1 such expect.
> 
> That assumes someone exists and is willing to do the work.  I don't
> think we can magically "have" such a port developed and gain such an
> expert.
> 
> Would you like to volunteer?

This discussion started with a person expressing interest.