Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 14:38, Eli Zaretskii wrote:

> > Before we could do that, we'd need to have this port functional first,
> > and the problem with dropping all others would be in reaching a
> > consensus across emacs-devel (at least) that the new one is better than
> > the others. And it maintained/maintainable, of course.
> >
> > 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.
>
> So you'd suggest to the OP to develop the software in the hope that
> all of the above will happen?  And if it doesn't, just agree for the
> results to be abandoned?  The OP would have to agree to that.

I suppose.

And I think the BeOS port had been accepted under the same conditions 
recently.

> And I fail to see how that solves the long-term maintenance problem,
> once we do accept the code.  This happened in the past, more than
> once.

We should be able to drop unmaintained ports. Even if we're reluctant, 
in general, to remove features that someone is using. After all, the 
history of changes is saved, so as soon as a volunteer arrives to 
resurrect it, they can start with 'git revert' and continue.

> > > I have nothing in principle against improving the no-toolkit
> > > configuration.  I do think that _adding_ another no-toolkit
> > > configuration would be undesirable, because it would make the
> > > proverbial "spaghetti of Emacs code" even harder to understand and
> > > maintain.  (I don't think such a suggestion is on the table, but since
> > > you seem to say I misunderstood the suggestion, perhaps I've
> > > misunderstood that as well.)
> >
> > 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.
>
> What would be the motivation for such a switch, as opposed to just
> incrementally improving the existing no-toolkit build?  Come to think
> of that, what exactly is the difference between these two
> alternatives?

In my mind, the new port would, similar to Blender, or VS Code, or IDEA, 
have their own set of widgets for menus, buttons, tabs, etc, which would 
remain consistent across platforms and look at least somewhat 
fresh/modern-ish. And it would support HiDPI scaling.

But the details are ultimately up to the developer.