Re: Platform independent graphical display for Emacs

[Dmitry Gutov <dgutov@yandex.ru>]

On 24.12.2021 10:33, Eli Zaretskii wrote:
>> That said, all of this would obviously be a lot of work and until and
>> unless someone starts such work this is all rather academic.
> Not only that, I'd hesitate to accept such a contribution, because its
> long-term maintenance would most probably be a constant burden,

How it that different from a BeOS port, or a PGTK port, or etc? Where 
the general policy has been (I think?) that we accept such contributions 
as long as there interest from the author in maintaining it, and some 
probable interest the users.

I would hate to discourage someone from taking the initiative a trying 
to create a better "no-toolkit" port which supports font scaling, for 
example. And also some existing interface details which people mentioned 
before (customize widgets, popups, tabs, scroll bars), which are 
currently not very well integrated with the existing toolkits, in a more 
organic way. Better performance would help, too (like child frames are 
faster on older ports than on GTK3 one).

 >  and if
 > the person(s) who develop such a "native" toolkit go on to greener
 > pastures, we will be left with an unmaintained subsystem.

Worst-case scenario, we'd just have to drop that "port", wouldn't we?

> So I don't think it is a good idea for Emacs to develop its own
> toolkit.  We should use what's out there.

Like some people said previously, Emacs feels similar in spirit to 
another popular FLOSS project: Blender. Community of professionals, 
keyboard-driven interface, power and customizability.

Blender never used an existing GUI toolkit. And I think it looks pretty 
good (even though I hope it has grown a light-bg theme by now):

https://docs.blender.org/manual/en/latest/_images/editors_preferences_section_interface.png
https://b3d.interplanety.org/wp-content/upload_content/2016/09/01-4.jpg

Of course, the Blender community is much larger and better funded, but 
OTOH the number of different UI elements we'd need to support is much 
smaller as well.

And we could tap into some existing community talent by having a lot of 
the UI logic implemented in Lisp. Similarly to how a number of recent 
web browser projects have their UIs implemented with JS+HTML.