Re: Motif support

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02225.html
From: Eli Zaretskii
Subject: Re: Motif support
Date: Wed, 22 Dec 2021 19:40:21 +0200

>> Games usually do all GUI drawing themselves.
> So you are saying that so should we??

Believe it or not, Emacs is much more reminiscent of a game engine than
a desktop app.  Also if definition of video game was; a software, use of
which instills high levels of fun to the user, by definition Emacs is one.
:)

Re: Motif support

[Arthur Miller]

xenodasein@tutanota.de writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02225.html
> From: Eli Zaretskii
> Subject: Re: Motif support
> Date: Wed, 22 Dec 2021 19:40:21 +0200
>
>>> Games usually do all GUI drawing themselves.
>> So you are saying that so should we??
>
> Believe it or not, Emacs is much more reminiscent of a game engine than
> a desktop app.
I was also thinking of same when I wrote my replay to Eli, but I didn't want to
took it up. :)

Re: Motif support

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 20:19:24 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: eliz@gnu.org, arthur.miller@live.com, ofv@wanadoo.es
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02225.html
> From: Eli Zaretskii
> Subject: Re: Motif support
> Date: Wed, 22 Dec 2021 19:40:21 +0200
> 
> >> Games usually do all GUI drawing themselves.
> > So you are saying that so should we??
> 
> Believe it or not, Emacs is much more reminiscent of a game engine than
> a desktop app.

I indeed don't believe it.

Re: Motif support

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Games usually do all GUI drawing themselves.
>> > So you are saying that so should we??
>> 
>> Believe it or not, Emacs is much more reminiscent of a game engine than
>> a desktop app.
>
> I indeed don't believe it.

I agree with the OP. Emacs does a lot of micro-management of graphical
elements and does its own event processing. That's distinctive of games.

Re: Motif support

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 21:24:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >> Games usually do all GUI drawing themselves.
> >> > So you are saying that so should we??
> >> 
> >> Believe it or not, Emacs is much more reminiscent of a game engine than
> >> a desktop app.
> >
> > I indeed don't believe it.
> 
> I agree with the OP. Emacs does a lot of micro-management of graphical
> elements and does its own event processing. That's distinctive of games.

There's a large chasm between "micro-management of graphical elements
and own event processing" and doing all the GUI by hand, bit by bit.
It is far from being black-and-white.  And Emacs is very far from the
edge you seem to be saying we are at or near.  You are invited to read
the code and see for yourself.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 22 Dec 2021 21:24:52 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> >> Games usually do all GUI drawing themselves.
>> >> > So you are saying that so should we??
>> >> 
>> >> Believe it or not, Emacs is much more reminiscent of a game engine than
>> >> a desktop app.
>> >
>> > I indeed don't believe it.
>> 
>> I agree with the OP. Emacs does a lot of micro-management of graphical
>> elements and does its own event processing. That's distinctive of games.
>
> There's a large chasm between "micro-management of graphical elements
> and own event processing" and doing all the GUI by hand, bit by bit.
> It is far from being black-and-white.  And Emacs is very far from the
> edge you seem to be saying we are at or near.  You are invited to read
> the code and see for yourself.

In a way a repl is kind of similar to a game loop in that it reads input (read),
update the world (eval) and render the world (print). The other similarity is
that Emacs is also controlling it's loop rather than fitting into some
frameworks loop such as Gtk, or some other toolkits framework. You rather use
those as a library of functionality to draw things when they suit Emacs, while
desktop applications would usually fit into a framework and let toolkit do the
update and drawing when it needs to be done. GUI toolkits like Gtk are usually
"don't call us, we call you", while games, and I perecive Emacs, are rather, "do
this for me when I ask you".

Maybe I missunderstand how Emacs works, but that is how I understood it.

Re: Motif support

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Thu, 23 Dec 2021 08:58:29 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> In a way a repl is kind of similar to a game loop in that it reads input (read),
> update the world (eval) and render the world (print). The other similarity is
> that Emacs is also controlling it's loop rather than fitting into some
> frameworks loop such as Gtk, or some other toolkits framework. You rather use
> those as a library of functionality to draw things when they suit Emacs, while
> desktop applications would usually fit into a framework and let toolkit do the
> update and drawing when it needs to be done. GUI toolkits like Gtk are usually
> "don't call us, we call you", while games, and I perecive Emacs, are rather, "do
> this for me when I ask you".

That difference is largely irrelevant in the context of this
particular discussion, since we are specifically talking about drawing
stuff, not about the framework or the main loop.

Re: Motif support

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 23 Dec 2021 08:58:29 +0100
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
>> 
>> In a way a repl is kind of similar to a game loop in that it reads input (read),
>> update the world (eval) and render the world (print). The other similarity is
>> that Emacs is also controlling it's loop rather than fitting into some
>> frameworks loop such as Gtk, or some other toolkits framework. You rather use
>> those as a library of functionality to draw things when they suit Emacs, while
>> desktop applications would usually fit into a framework and let toolkit do the
>> update and drawing when it needs to be done. GUI toolkits like Gtk are usually
>> "don't call us, we call you", while games, and I perecive Emacs, are rather, "do
>> this for me when I ask you".
>
> That difference is largely irrelevant in the context of this
> particular discussion, since we are specifically talking about drawing
> stuff, not about the framework or the main loop.

Well it is what it is about, how Emacs draw the world (or rather buffers). Since
Emacs uses toolkit in that fashion, and it already pretends that a gui window is
a text terminal (as D. Colascione put it in one old text he wrote), Emacs can as
well use it's own library functions to do the gui, and just use a (relatively)
tiny wrapper for os/hardware to implement that abstraction.

I suggested Cairo or gdk as such, but that does not seem to be popular for
different reasons you and Po mentioned, but there might be other ones already
written that could be suitable.

I have understanding that you hae implemented quite advanced text renderer at
least on X; I am not sure if you do same on win32 or Emacs uses built-in OS text
rendering on Windows. In that light, I wonder if Emacs even need 3rd party
abstraction and toolkits other than for, as you said in the beginning of the
thread, to fit into looks of the platform.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> I have understanding that you hae implemented quite advanced text
> renderer at least on X;  I am not sure if you do same on win32 or Emacs
> uses built-in OS text rendering on Windows.

Emacs doesn't implement its own text renderer anywhere, I think.  We use
libraries that can be considered part of the system for that everywhere.

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I have understanding that you hae implemented quite advanced text
>> renderer at least on X;  I am not sure if you do same on win32 or Emacs
>> uses built-in OS text rendering on Windows.
>
> Emacs doesn't implement its own text renderer anywhere, I think.  We use
> libraries that can be considered part of the system for that everywhere.
I think I have expressed myself badly here; anyway what I meant, Emacs could use
pango and harfbuzz and whatever else it uses on X together with freetype2 to render
text on all platforms. 

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> I think I have expressed myself badly here; anyway what I meant, Emacs
> could use pango and harfbuzz and whatever else it uses on X together
> with freetype2 to render text on all platforms.

We don't use Pango on X for anything more than converting the output of
the GTK font selection dialog to a font spec.

HarfBuzz is already used on MS-Windows, and the idea is to eventually
use it on macOS as well.

As for using FreeType, what benefit would it bring?  Rendering text with
FreeType is not very easy and involves writing a lot of interface code
for each platform, often more than using the platform's built-in
interface.  (For simple examples, see the deleted ftx driver, or the
ftbe driver that was deleted, and for non-trivial examples, see
ftcrfont.c and xftfont.c.)

It usually involves Fontconfig as well, which doesn't work very well
non-Unix systems.

Re: Motif support

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I think I have expressed myself badly here; anyway what I meant, Emacs
>> could use pango and harfbuzz and whatever else it uses on X together
>> with freetype2 to render text on all platforms.
>
> We don't use Pango on X for anything more than converting the output of
> the GTK font selection dialog to a font spec.
>
> HarfBuzz is already used on MS-Windows, and the idea is to eventually
> use it on macOS as well.
>
> As for using FreeType, what benefit would it bring?  Rendering text with
The benefit of using unified platform and not needing to use os built-ins?
This discussion started with someone wanted Emacs to do it's own drawing since
Emacs GUI is relatively simple and does not require full-fledged GUI
toolkit. Freetype would be one tool to achieve this.

>                                                      Rendering text with
> FreeType is not very easy and involves writing a lot of interface code
> for each platform, often more than using the platform's built-in
> interface.  (For simple examples, see the deleted ftx driver, or the
I dont understand what different interfaces are with freetype you are talking
about nor what is difficult with freetype? Freetype gives you platform
independent interface to read, parse and render fonts files to bitmaps. You can
also do your own rendering if you want. Lots of platform independent
applications use Freetype to render fonts.

> It usually involves Fontconfig as well, which doesn't work very well
> non-Unix systems.

Freetype does not need fontconfig. I don't understand why bring fontconfig
here. Fontcnfig uses freetype to read and parse font files, but freetype does
not need fontconfig. 

Anyway, I find this discusion with you immature. You are sitting here and trying
to find anything opposite for the sake of sake of saying opposite. Sorry, all
best to you, I wish you Merry Christmass and all best, but I am out.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> The benefit of using unified platform and not needing to use os
> built-ins?  This discussion started with someone wanted Emacs to do
> it's own drawing since Emacs GUI is relatively simple and does not
> require full-fledged GUI toolkit. Freetype would be one tool to
> achieve this.

That benefit is hardly established.

> I dont understand what different interfaces are with freetype you are
> talking about nor what is difficult with freetype? Freetype gives you
> platform independent interface to read, parse and render fonts files
> to bitmaps. You can also do your own rendering if you want. Lots of
> platform independent applications use Freetype to render fonts.

What about locating the font files to open? Scaling glyphs, which is
usually the job of the platform, and essentially required for color
Emoji? What about displaying the resulting bitmap, or decomposed glyph
outline?

All those tasks need platform-dependent code, and about the same amount
as supporting the native font rasterizer.

> Freetype does not need fontconfig. I don't understand why bring
> fontconfig here. Fontcnfig uses freetype to read and parse font files,
> but freetype does not need fontconfig.

Then take a look at ftfont.c, the "abstract" FreeType font driver,
unless you're saying we should also reinvent the (platform-specific)
code to detect and use installed fonts?

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 03:38 by luangruo@yahoo.com:

> That benefit is hardly established.
>

We could establish deeper, but any developer who worked
on both traditional desktop apps or graphical apps with their
own rendering like "games" will tell you same things.


> What about locating the font files to open? Scaling glyphs, which is
> usually the job of the platform, and essentially required for color
> Emoji? What about displaying the resulting bitmap, or decomposed glyph
> outline?
>
> All those tasks need platform-dependent code, and about the same amount
> as supporting the native font rasterizer.
>
> Then take a look at ftfont.c, the "abstract" FreeType font driver,
> unless you're saying we should also reinvent the (platform-specific)
> code to detect and use installed fonts?
>

You kinda have to use platform dependent features directly, as we
are not programming into aether.  However, painting menus isn't one.
You don't need a third-party solution, whether it is from platform itself
like legacy win32 GUI elements or another library.  Using them is like
using a sledgehammer to drive a nail in Emacs' case. We could even do
the text rendering itself too, provided an expert would contribute it to
Emacs.  But no one said let's do text rendering, AFAIK.

Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> You kinda have to use platform dependent features directly, as we are
> not programming into aether. However, painting menus isn't one.  You
> don't need a third-party solution, whether it is from platform itself
> like legacy win32 GUI elements or another library. Using them is like
> using a sledgehammer to drive a nail in Emacs' case. We could even do
> the text rendering itself too, provided an expert would contribute it
> to Emacs.

That is simply untrue.  Besides, people _want_ the platform specific
widgets, or otherwise we'd just be porting oldXMenu everywhere.

> But no one said let's do text rendering, AFAIK.

That's what Authur said about FreeType.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 04:24 by luangruo@yahoo.com:

> That is simply untrue.  Besides, people _want_ the platform specific
> widgets, or otherwise we'd just be porting oldXMenu everywhere.
>

I agree those should remain as long as there is demand and someone
who knows how to maintain them, just like text interface still works
despite being the less popular choice.

Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 02:37:32 +0100 (CET)
> Cc: emacs-devel@gnu.org
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> text interface still works despite being the less popular choice.

I invite you to read the Emacs Reddit for some time, where you will
learn that quite a few people use the text-mode UI _by_choice_.  It's
quite popular.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 10:24 by eliz@gnu.org:

>> Date: Fri, 24 Dec 2021 02:37:32 +0100 (CET)
>> Cc: emacs-devel@gnu.org
>> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
>> text interface still works despite being the less popular choice.
>>
>
> I invite you to read the Emacs Reddit for some time, where you will
> learn that quite a few people use the text-mode UI _by_choice_.  It's
> quite popular.
>

I know, I am one of them, and I mentioned it several times.
Emacs' text interface is less popular than it's GUI.
Is previous statement false?  That is what I said there.

Re: Motif support

[Stefan Kangas]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Emacs' text interface is less popular than it's GUI.
> Is previous statement false?  That is what I said there.

Among the respondents in the Emacs Survey last year, 91.5 % used
graphical Emacs, and 31.9 % used it in the terminal.

    https://emacssurvey.org/2020/

Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 09:06:21 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> Dec 24, 2021, 10:24 by eliz@gnu.org:
> 
> >> Date: Fri, 24 Dec 2021 02:37:32 +0100 (CET)
> >> Cc: emacs-devel@gnu.org
> >> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> >> text interface still works despite being the less popular choice.
> >>
> >
> > I invite you to read the Emacs Reddit for some time, where you will
> > learn that quite a few people use the text-mode UI _by_choice_.  It's
> > quite popular.
> >
> 
> I know, I am one of them, and I mentioned it several times.
> Emacs' text interface is less popular than it's GUI.
> Is previous statement false?

It isn't clear to me whether it is true or false.  The text-mode UI is
popular enough to not make any assumptions here.

Re: Motif support

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> That is simply untrue.  Besides, people _want_ the platform specific
> widgets,

Do they?  VSCode is pretty popular, and their users don't seem to care
about that at all.

FWIW, I think it would be highly preferable if Emacs could look and
behave the same across all platforms.

Re: Motif support

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Do they?  VSCode is pretty popular, and their users don't seem to care
> about that at all.

I don't know about VS Code, but IntelliJ IDEA has the same decoration
style everywhere, and many people at work seem to complain about that.

RE: [External] : Re: Motif support

[Drew Adams]

> FWIW, I think it would be highly preferable if Emacs
> could look and behave the same across all platforms.

OK, why do you think that would be highly preferable?

Could, or must?  If there were an option that enabled
that, that would be one thing.  Making that happen as
the only choice would be something else.

How similar are you aiming for?  And would that be by
limiting what's possible on some platforms (lowest
common denominator)?

RE: [External] : Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 05:59 by drew.adams@oracle.com:

>> FWIW, I think it would be highly preferable if Emacs
>> could look and behave the same across all platforms.
>>
>
> OK, why do you think that would be highly preferable?
>
> Could, or must?  If there were an option that enabled
> that, that would be one thing.  Making that happen as
> the only choice would be something else.
>
> How similar are you aiming for?  And would that be by
> limiting what's possible on some platforms (lowest
> common denominator)?
>

Damn, I wasn't planning to work on a renderer for Emacs
when I decided get active. :)  It would essentially be a
"Third Way."  Whereas currently there is two, it would be
"Emacs the Terminal", "Emacs the Gedit" and "Emacs the ?"
First runs even without X, second is we are used to.  They
don't necessarily hinder each other.

Re: [External] : Re: Motif support

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> "Emacs the ?"  First runs even without X, second is we are used to. 
> They don't necessarily hinder each other.

In other words, you want a build of Emacs with `--with-x-toolkit=no'?
Where the menu bar, tool bar, and scroll bar are all displayed by Emacs
itself?

That already exists.

Re: [External] : Re: Motif support

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 06:26 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> "Emacs the ?"  First runs even without X, second is we are used to. 
>> They don't necessarily hinder each other.
>>
>
> In other words, you want a build of Emacs with `--with-x-toolkit=no'?
> Where the menu bar, tool bar, and scroll bar are all displayed by Emacs
> itself?
>
> That already exists.
>

This lack of imagination is disheartening.

Re: [External] : Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 04:36:31 +0100 (CET)
> Cc: emacs-devel@gnu.org, Stefan Kangas <stefankangas@gmail.com>,
>  Drew Adams <drew.adams@oracle.com>
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> > In other words, you want a build of Emacs with `--with-x-toolkit=no'?
> > Where the menu bar, tool bar, and scroll bar are all displayed by Emacs
> > itself?
> >
> > That already exists.
> >
> 
> This lack of imagination is disheartening.

Perhaps you haven't explained yourself well enough for us to imagine
that.

Platform independent graphical display for Emacs

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> FWIW, I think it would be highly preferable if Emacs
>> could look and behave the same across all platforms.
>
> OK, why do you think that would be highly preferable?

I don't think that what we do necessarily translates very well to the
widgets provided by common toolkits.  For example, the mode line is not
rendered by a toolkit.

OTOH, I can see plenty of benefits with doing things ourselves.

With regards to tooltips, in VSCode they can also include links to
relevant actions.  I don't think we can currently do that (or e.g. use
faces and have them work).

Dialogs are basically not very useful or Emacsy as is.  When they pop
up, you are completely outside of "Emacs land", and there is no way for
us to add keybindings, style them, etc. or do much of anything really.

Our scrollbars are fairly subpar compared to the ones in VSCode, at
least in GTK.  Admittedly that might be to some extent because it is
hard to style them from Lisp themes (I guess that's not currently
possible).

There is a similar story with the tab bar, tab line and toolbar.

Then we have things like the posframe package, where the minibuffer pops
up on top of the current buffers.  That currently works with a hack (a
separate frame) but we could imagine having our own widget for that.
IMO, we would ideally want that to look the same across platforms.

I think there are many more things that we could do if we wanted to.
You can fire up an editor made by the competition and see what they do
for more ideas.

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.

> How similar are you aiming for?

No idea.  I guess the menus would be different on macOS.

> And would that be by limiting what's possible on some platforms
> (lowest common denominator)?

I don't think it would necessarily imply that, no.

Re: Platform independent graphical display for Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> I don't think that what we do necessarily translates very well to the
> widgets provided by common toolkits.  For example, the mode line is
> not rendered by a toolkit.

That's because it's part of an Emacs window, not a widget.

> Dialogs are basically not very useful or Emacsy as is.  When they pop
> up, you are completely outside of "Emacs land", and there is no way for
> us to add keybindings, style them, etc. or do much of anything really.

Just as in gedit and other graphical editors, no?

> Our scrollbars are fairly subpar compared to the ones in VSCode, at
> least in GTK.  Admittedly that might be to some extent because it is
> hard to style them from Lisp themes (I guess that's not currently
> possible).

The built-in (as in, no toolkit) scrollbar is even worse, though can be
styled via some X resources.

> There is a similar story with the tab bar, tab line and toolbar.

The tool bar is displayed by Emacs itself on all platforms except GTK
and NS, and the tab line and tab bar are always displayed by Emacs
itself.

> Then we have things like the posframe package, where the minibuffer pops
> up on top of the current buffers.  That currently works with a hack (a
> separate frame) but we could imagine having our own widget for that.
> IMO, we would ideally want that to look the same across platforms.

Child frames basically look the same regardless of platform, as long as
window decorations are turned off (if they are on, again, that's outside
our control).  They are even implemented the same way widgets are on X,
via an X window with a parent, so I don't really see the difference.

> No idea.  I guess the menus would be different on macOS.

NS users will complain.  Besides, I find the global menu bar concept
rather nice from my limited usage of GNUstep, and I hope more programs
will grow to support such behaviour.

It is certainly better than the fat-finger-button-hamburger-menu GNOME
people want these days.

Re: Platform independent graphical display for Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> I don't think that what we do necessarily translates very well to the
>> widgets provided by common toolkits.  For example, the mode line is
>> not rendered by a toolkit.
>
> That's because it's part of an Emacs window, not a widget.

Yes.  I was under the impression that this was well understood, and
didn't need pointing out.

>> Dialogs are basically not very useful or Emacsy as is.  When they pop
>> up, you are completely outside of "Emacs land", and there is no way for
>> us to add keybindings, style them, etc. or do much of anything really.
>
> Just as in gedit and other graphical editors, no?

Yes, but I expect more from Emacs than from other editors.

>> Our scrollbars are fairly subpar compared to the ones in VSCode, at
>> least in GTK.
>
> The built-in (as in, no toolkit) scrollbar is even worse,

That's true, but to be clear I am not talking about that build.

> Child frames basically look the same regardless of platform, as long as
> window decorations are turned off (if they are on, again, that's outside
> our control).  They are even implemented the same way widgets are on X,
> via an X window with a parent, so I don't really see the difference.

I don't really understand your argument here; I see a significant
difference between widgets and frames.

>> No idea.  I guess the menus would be different on macOS.
>
> NS users will complain.

I meant that the menus would likely be global on macOS.  I think you
will agree that they would not complain about that.

Re: Platform independent graphical display for Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Yes, but I expect more from Emacs than from other editors.

How about we extend the existing menus to do whatever couldn't be done
before, which presumably compelled you to ask this question?

> I don't really understand your argument here; I see a significant
> difference between widgets and frames.

If we implemented some kind of popup widget, it would probably be
implemented similarly to child frames.

> I meant that the menus would likely be global on macOS.  I think you
> will agree that they would not complain about that.

I'm fine by that then, but that means we won't be able to draw the menus
ourselves (it is actually not possible under NS).

Thanks.

RE: [External] : Platform independent graphical display for Emacs

[Drew Adams]

> >> FWIW, I think it would be highly preferable if Emacs
> >> could look and behave the same across all platforms.
> >
> > OK, why do you think that would be highly preferable?
> 
> I don't think that what we do necessarily translates very well to the
> widgets provided by common toolkits.  For example, the mode line is not
> rendered by a toolkit.  OTOH, I can see plenty of benefits with doing
> things ourselves.

I see that you changed the topic (and the Subject line).
OK.

What you had said was that it's preferable for Emacs to
have the same look & feel across all platforms.  That's
what I responded to, with questions about that.

Now you're talking about the question of Emacs itself
implementing things, instead of relying on toolkits
etc.  That's not the same proposal/question.

Assuming Emacs dev provided everything, without relying
on toolkits etc. provided by/for particular platforms
etc., why would it be highly preferable for Emacs to
provide only one look and behavior across all platforms?

I ask about "only one", because, as I said, _allowing_
for the same everywhere is one thing.  _Not allowing_
for any differences is a different thing.

If the aim is to limit Emacs behavior to be only what
can be made available to all platforms (lowest common
denominator), then I think that would be unfortunate
(too limiting, for no particular gain).

IIUC, one explicit aim is to have GNU/Linux be the
most feature-full, out of the box.  Emacs doesn't
pursue development that's only for MS Windows, for
example.  But nothing currently limits Emacs to
providing only behavior that works on all platforms.
___

As for what you're talking about now: I don't have
a problem with that.  If Emacs develops improved
tooltips, dialog boxes, menus, or whatever, so much
the better.  I'm assuming that there's no policy
road-block in the way of that, and that all that's
perhaps lacking is enough volunteer energy.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 23 Dec 2021 20:30:42 -0800
> 
> With regards to tooltips, in VSCode they can also include links to
> relevant actions.  I don't think we can currently do that (or e.g. use
> faces and have them work).

In toolkit-provided tooltips, we don't.  But Emacs has its own native
tooltips, where everything that works in a "normal" frame can work in
a tooltip.

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

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

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02518.html
From: Eli Zaretskii

> Not only that, I'd hesitate to accept such a contribution, because its
> long-term maintenance would most probably be a constant burden, and if
> the person(s) who develop such a "native" toolkit go on to greener
> pastures, we will be left with an unmaintained subsystem.
>
> So I don't think it is a good idea for Emacs to develop its own
> toolkit.  We should use what's out there.
>

Please take a look, and try to understand my frustration.

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02034.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02517.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02515.html

It would be nice to mention this before sending me on my way to
waste time.  I should have suspected you were going to do that
but I regrettably have taken the course of assuming good faith first.

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02221.html

Also very relevant:

https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg00885.html

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 09:10:20 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, drew.adams@oracle.com,
> 	rms@gnu.org
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02518.html
> From: Eli Zaretskii
> 
> > Not only that, I'd hesitate to accept such a contribution, because its
> > long-term maintenance would most probably be a constant burden, and if
> > the person(s) who develop such a "native" toolkit go on to greener
> > pastures, we will be left with an unmaintained subsystem.
> >
> > So I don't think it is a good idea for Emacs to develop its own
> > toolkit.  We should use what's out there.
> >
> 
> Please take a look, and try to understand my frustration.

I apologize for causing frustration, but if that was what you meant
from the beginning, it was (and still is) hard for me to understand
that this is the way you intend to go.  It is a misunderstanding, and
I apologize for my part of it.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 11:41 by eliz@gnu.org:

> I apologize for causing frustration, but if that was what you meant
> from the beginning, it was (and still is) hard for me to understand
> that this is the way you intend to go.  It is a misunderstanding, and
> I apologize for my part of it.
>

I gladly accept it, I also apologize because I am also aware
that I am neither a clear nor a refined mailer.

Also I feel like there is a case to be made there somewhere,
about perils of mail driven development, but I don't want
to force my luck. :)

Cheers.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

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.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Cc: luangruo@yahoo.com, drew.adams@oracle.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 25 Dec 2021 02:30:25 +0200
> 
> 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.

The suggestion, as I understood it, was to drop all the other toolkits
and leave only this proposed one.  That was its main "selling point".
If we decide to have just one toolkit, then having that unmaintained
would be a serious problem for the future of Emacs.

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

The suggestion was not to improve the no-toolkit configuration and
leave all the supported toolkits in place.  The suggestion was to drop
all the others.

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

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

We cannot just "drop" the only toolkit we have.

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

I'm not saying it's impossible, I'm just saying we don't have such
talent on board.  Maybe Blender does, which would be understandable,
given the focus of the project.  Our experience is that GUI experts in
our ranks are very rare and far in-between, and there are no reasons
to believe this will change.

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

I think this hope is misguided, because Emacs Lisp was not designed to
be a UI programming language, it was designed as a text-processing
language.  So it would need significant extensions to get closer to
your dream.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 10:25, Eli Zaretskii wrote:

>> 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.
> 
> The suggestion, as I understood it, was to drop all the other toolkits
> and leave only this proposed one.  That was its main "selling point".
> If we decide to have just one toolkit, then having that unmaintained
> would be a serious problem for the future of Emacs.

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.

>> 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.
> 
> The suggestion was not to improve the no-toolkit configuration and
> leave all the supported toolkits in place.  The suggestion was to drop
> all the others.
> 
> 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.

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.

>> Worst-case scenario, we'd just have to drop that "port", wouldn't we?
> 
> We cannot just "drop" the only toolkit we have.
> 
>> 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.
> 
> I'm not saying it's impossible, I'm just saying we don't have such
> talent on board.  Maybe Blender does, which would be understandable,
> given the focus of the project.  Our experience is that GUI experts in
> our ranks are very rare and far in-between, and there are no reasons
> to believe this will change.

Having a port like that developed could get us +1 such expect.

>> 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.
> 
> I think this hope is misguided, because Emacs Lisp was not designed to
> be a UI programming language, it was designed as a text-processing
> language.  So it would need significant extensions to get closer to
> your dream.

There is not much in JS that would make it a UI language. Other Lisps 
compile to it without problems. Other editors had been written in lisp 
as well (such a LightTable -- in ClojureScript).

Perhaps better concurrency story would make it a tad easier (e.g. better 
stdlib for working with threads, or a counterpart to Web Workers), but 
IIRC when LightTable was developed, JavaScript had neither.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Cc: stefankangas@gmail.com, luangruo@yahoo.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 25 Dec 2021 13:23:01 +0200
> 
> On 25.12.2021 10:25, Eli Zaretskii wrote:
> 
> >> 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.
> > 
> > The suggestion, as I understood it, was to drop all the other toolkits
> > and leave only this proposed one.  That was its main "selling point".
> > If we decide to have just one toolkit, then having that unmaintained
> > would be a serious problem for the future of Emacs.
> 
> 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.

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.

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

> It might become feasible to remove a number of them, though.

So far we've failed to do that.

> > I'm not saying it's impossible, I'm just saying we don't have such
> > talent on board.  Maybe Blender does, which would be understandable,
> > given the focus of the project.  Our experience is that GUI experts in
> > our ranks are very rare and far in-between, and there are no reasons
> > to believe this will change.
> 
> Having a port like that developed could get us +1 such expect.

Yes, miracles and improbable events do happen sometimes.  But planning
our future on that hope is unwise at best.  If and when that happens,
then we should probably grab the opportunity, but we are not there
now, I think.

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.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Cc: stefankangas@gmail.com, luangruo@yahoo.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 25 Dec 2021 13:57:40 +0200
> 
> > 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.

Because we did have someone who volunteered, and because nothing would
be lost on platforms of interest to us if the BeOS port bitrots.

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

Once again, a single toolkit on which all the platforms depend cannot
be dropped.  So it's a huge difference from the BeOS port.

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

That's generally not a practical possibility, because the code changes
very rapidly, and what you revert won't even compile in most cases.

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

So your dream is even more in the fantasy-land than I thought.  Of
course, even such fantasies could come true if we have someone to do
the job and stick around to keep it working.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:06, Eli Zaretskii wrote:
>> Cc: stefankangas@gmail.com, luangruo@yahoo.com, drew.adams@oracle.com,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 25 Dec 2021 13:57:40 +0200
>>
>>> 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.
> 
> Because we did have someone who volunteered, and because nothing would
> be lost on platforms of interest to us if the BeOS port bitrots.

Which would be also true when someone initially proposes the new "single 
toolkit" port for inclusion.

>>> 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.
> 
> Once again, a single toolkit on which all the platforms depend cannot
> be dropped.  So it's a huge difference from the BeOS port.

Once again: we would only get to that point after the "single toolkit" 
port is functional, accepted by the majority of us, and probably 
"adopted" by a few regular contributors as their area of interest.

Only then we could realistically vote to drop all other ports.

I'm sure a contributor who would propose such new port would understand 
all of this.

>> 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.
> 
> That's generally not a practical possibility, because the code changes
> very rapidly, and what you revert won't even compile in most cases.

Yes and no: I'm sure having the previous code available will be a lot of 
help. As opposed to rewriting the same port from scratch.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Cc: stefankangas@gmail.com, luangruo@yahoo.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 25 Dec 2021 14:59:34 +0200
> 
> > Because we did have someone who volunteered, and because nothing would
> > be lost on platforms of interest to us if the BeOS port bitrots.
> 
> Which would be also true when someone initially proposes the new "single 
> toolkit" port for inclusion.

No, it won't.  The "single" part makes the crucial difference.

> > Once again, a single toolkit on which all the platforms depend cannot
> > be dropped.  So it's a huge difference from the BeOS port.
> 
> Once again: we would only get to that point after the "single toolkit" 
> port is functional, accepted by the majority of us, and probably 
> "adopted" by a few regular contributors as their area of interest.
> 
> Only then we could realistically vote to drop all other ports.

You are responding to what I wrote on the assumption that this was
being proposed up front.

> I'm sure a contributor who would propose such new port would understand 
> all of this.

That wasn't my understanding.

> > That's generally not a practical possibility, because the code changes
> > very rapidly, and what you revert won't even compile in most cases.
> 
> Yes and no: I'm sure having the previous code available will be a lot of 
> help. As opposed to rewriting the same port from scratch.

Much more is needed than just the code which at some point did work.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

I don't plan to abandon it, and besides, it's not vital for the
functioning of Emacs.

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

IMO, we should just let them be.  If someone notices once they get
broken, and is interested in fixing them, he will probably do that.

There's also the chance that an unmaintained port will simply continue
to work.

I think that's the situation with the MS-DOS port as well.

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

Please see my other reply to you on why that's simply not feasible for a
single expert, which we will probably not even get.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:06, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> And I think the BeOS port had been accepted under the same conditions
>> recently.
> 
> I don't plan to abandon it,

It's still bus factor of 1.

>> 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.
> 
> IMO, we should just let them be.  If someone notices once they get
> broken, and is interested in fixing them, he will probably do that.
> 
> There's also the chance that an unmaintained port will simply continue
> to work.
> 
> I think that's the situation with the MS-DOS port as well.

That's just the argument of when we call a port "unmaintained". E.g., I 
would say a port is unmaintained when there are known usability-breaking 
bugs. Or you can call it that when it stops compiling (for a certain 
period of time).

But there *is* value in dropping unused ports: the trimming of the 
#ifdefs forest, as well as less work for regular contributors to keep 
code compiling under various conditions.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But there *is* value in dropping unused ports: the trimming of the
> #ifdefs forest, as well as less work for regular contributors to keep
> code compiling under various conditions.

I took care to keep the ifdefs down to a minimum when developing the
Haiku port.  I would consider it being referred to as an "ifdef forest"
to be an insult.

IME, image.c and xterm.c are the only places where an "ifdef forest"
related to toolkits and window systems really exists.  With image.c,
someone just has to put the work required to clean it up, there need not
be any changes elsewhere.

With xterm.c, 90% of the problem is GTK.  Other toolkits and the
no-toolkit build don't really contribute to the "maze of ifdefs" effect.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

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

Why oh why you don't just say "go ahead and we will look at your work
when you have something to show" ?

Then, after a long time (because this project will require a loooong
time) *if* something comes out, you evaluate the result as any other
contribution and decide what to do. Why so many "what-ifs" before even
seeing the first patch and without understanding the proposal in full?
(see below.)

This is very discouraging, not only for the OP, but for any bystander
would-be contributor.

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

Yes, because having a single, modern, sane, popular cross-platform
graphics library (let's say Skia, for instance) would make things much
worse than the current status-quo, with N entangled backends requiring
the participation of multiple experts every time a new feature is
implemented :-/

To insist: the proposed system would have three characteristics:

1. Cross-platform (as the proposal's subject says)

2. Simplicity, compared to what we have now.

3. New graphical capabilities that will make possible new high-level
   features.

I don't know why you keep ignoring point 3, which is the most important,
and reduce the proposal to "oh, someone wants to add one more graphical
backend."

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Yes, because having a single, modern, sane, popular cross-platform
> graphics library (let's say Skia, for instance) would make things much
> worse than the current status-quo, with N entangled backends requiring
> the participation of multiple experts every time a new feature is
> implemented :-/

No "cross-platform graphics library" is either truly cross-platform or
acceptable for our purposes.

Skia itself is simply a no-goer.  That abomination is impossible to
build outside the context of Chromium (or some other Google-endorsed
program).  Their API is also unstable and changes rapidly.

On the other hand, the current status quo seems to work: I can't really
think of an instance where the people interested in a port to a
different platform didn't spend the small effort required to implement a
new feature in Emacs to that platform.

And that effort is usually minor.  It took me about 15 minutes to add
tab bar support to the NS port, for example, and that was without any
prior experience in both the NS port code and Cocoa in general.

> 3. New graphical capabilities that will make possible new high-level
>    features.

> I don't know why you keep ignoring point 3, which is the most important,
> and reduce the proposal to "oh, someone wants to add one more graphical
> backend."

Please explain in detail what the new graphical capabilities are, and
how using a different graphics library will help.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:29, Po Lu wrote:
> Skia itself is simply a no-goer.  That abomination is impossible to
> build outside the context of Chromium (or some other Google-endorsed
> program).

I really wouldn't call Mozilla Firefox a Google-endorsed program at this 
point.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.12.2021 15:29, Po Lu wrote:

> I really wouldn't call Mozilla Firefox a Google-endorsed program at
> this point.

Firefox spends much of its time dealing with Skia breakage (and I think
only supports being built with a particular version of Skia at any
time.)

Their development team is also many orders of magnitudes larger, and
they get paid.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 15:54, Po Lu wrote:
> Their development team is also many orders of magnitudes larger, and
> they get paid.

OTOH, the surface area of their code dealing with Skia must be much 
larger as well.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> OTOH, the surface area of their code dealing with Skia must be much
> larger as well.

"Surface area" doesn't really matter when Skia developers make changes
to fundamental features at random.

From a maintainability perspective, Cairo is much better for a program
like Emacs.  The portability problems are basically the same with both
libraries.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Yes, because having a single, modern, sane, popular cross-platform
>> graphics library (let's say Skia, for instance) would make things much
>> worse than the current status-quo, with N entangled backends requiring
>> the participation of multiple experts every time a new feature is
>> implemented :-/
>
> No "cross-platform graphics library" is either truly cross-platform or
> acceptable for our purposes.

Because you know them all and you, and only you, define what is
acceptable for our purposes.

> Skia itself is simply a no-goer.  That abomination is impossible to
> build outside the context of Chromium

Just to check your assertion, I tried to build Skia on my Debian box
and, sure enough, after ten minutes of work the build succesfully
completed. I had some issues that were swiftly solved with a web search.
No Chromium involved, not even for doing the web search ;-)

A closer look at Skia makes me think that it is not a good candidate for
Emacs, for several reasons. But Skia was just an example, we (or, better
said, the OP) can examine what other options are available.

>> 3. New graphical capabilities that will make possible new high-level
>>    features.
>
>> I don't know why you keep ignoring point 3, which is the most important,
>> and reduce the proposal to "oh, someone wants to add one more graphical
>> backend."
>
> Please explain in detail what the new graphical capabilities are, and
> how using a different graphics library will help.

We could turn the frame into a canvas. Take
display-fill-column-indicator for instance. Instead of faking a line
with characters, we could simply draw the line as a graphic object.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 25 Dec 2021 14:09:02 +0100
> 
> A closer look at Skia makes me think that it is not a good candidate for
> Emacs, for several reasons. But Skia was just an example, we (or, better
> said, the OP) can examine what other options are available.

Yes, examples are being thrown here and there without any relevance,
just to make a point in a dispute, it seems.  It doesn't help to have
a useful discussion.

> > Please explain in detail what the new graphical capabilities are, and
> > how using a different graphics library will help.
> 
> We could turn the frame into a canvas. Take
> display-fill-column-indicator for instance. Instead of faking a line
> with characters, we could simply draw the line as a graphic object.

If you think this kind of enhancement could materialize just by
changing the *term backends of the Emacs display, you don't have a
clear idea about the relevant architecture aspects of that.  It is
nigh impossible to do something like that without the knowledge of
xdisp.c and dispnew.c.  I'm telling you that as the single person
around here who has any kind of practical experience in implementing
something like that: the TTY menus do something very similar, and that
code gets away by the skin of its teeth, and would be probably simply
impossible with GUI display.

Throwing around such ideas without any real knowledge is simply
irresponsible.  Someone might believe you and spend some non-trivial
time trying to implement that.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> A closer look at Skia makes me think that it is not a good candidate for
>> Emacs, for several reasons. But Skia was just an example, we (or, better
>> said, the OP) can examine what other options are available.
>
> Yes, examples are being thrown here and there without any relevance,
> just to make a point in a dispute, it seems.  It doesn't help to have
> a useful discussion.

It also happens that people make a big fuss over minor details instead
of dicussing the meat of the matter.

I don't think the outcome of this "dispute" depends on an example of
what it could be used. 

BTW, on the Skia-Emacs inadequacy issue, I would not be sure about what
part to blame the most.

>> > Please explain in detail what the new graphical capabilities are, and
>> > how using a different graphics library will help.
>> 
>> We could turn the frame into a canvas. Take
>> display-fill-column-indicator for instance. Instead of faking a line
>> with characters, we could simply draw the line as a graphic object.
>
> If you think this kind of enhancement could materialize just by
> changing the *term backends of the Emacs display, you don't have a
> clear idea about the relevant architecture aspects of that.  It is
> nigh impossible to do something like that without the knowledge of
> xdisp.c and dispnew.c.  I'm telling you that as the single person
> around here who has any kind of practical experience in implementing
> something like that: the TTY menus do something very similar, and that
> code gets away by the skin of its teeth, and would be probably simply
> impossible with GUI display.
>
> Throwing around such ideas without any real knowledge is simply
> irresponsible.  Someone might believe you and spend some non-trivial
> time trying to implement that.

You are overthinking something that's actually very simple: locating the
x coordinate of the n-th column and drawing a vertical line from top to
bottom of the window on each redisplay. Any sane graphics system can do
that simple, trivial thing. If it is difficult to do it in Emacs, that
only demonstrates how limited the display engine is on its capabilities.

If I were the hacker implementing the proposal, I would start with the
data structures that hold what needs to be shown and with a surface:
then, do the rendering. I know it is not as straightfordward as just
throwing a bunch of text on a textbox, but what I've seen on the sources
and your claims makes me think that any attempt at reusing the legacy
code (the one that actually paints the frame's contents) would be a
waste of time.

You are talking as if the complexity, quirks and limitations of Emacs'
display engine were something good, something to be preserved, when it
is quite the contrary, ever more when so few people understands it. By
your description, the current display engine is a big liability and any
proposal that could end with replacing it with something comprehensible
by mere mortals should be welcome.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 25 Dec 2021 15:08:17 +0100
> 
> > If you think this kind of enhancement could materialize just by
> > changing the *term backends of the Emacs display, you don't have a
> > clear idea about the relevant architecture aspects of that.  It is
> > nigh impossible to do something like that without the knowledge of
> > xdisp.c and dispnew.c.  I'm telling you that as the single person
> > around here who has any kind of practical experience in implementing
> > something like that: the TTY menus do something very similar, and that
> > code gets away by the skin of its teeth, and would be probably simply
> > impossible with GUI display.
> >
> > Throwing around such ideas without any real knowledge is simply
> > irresponsible.  Someone might believe you and spend some non-trivial
> > time trying to implement that.
> 
> You are overthinking something that's actually very simple: locating the
> x coordinate of the n-th column and drawing a vertical line from top to
> bottom of the window on each redisplay.

I think you have very inaccurate idea of what a redisplay cycle looks
like.

> If I were the hacker implementing the proposal, I would start with the
> data structures that hold what needs to be shown and with a surface:
> then, do the rendering. I know it is not as straightfordward as just
> throwing a bunch of text on a textbox, but what I've seen on the sources
> and your claims makes me think that any attempt at reusing the legacy
> code (the one that actually paints the frame's contents) would be a
> waste of time.

You are actually talking about redesigning the current display engine.
Which is a Good Thing, I think, because it was designed 23 years ago,
and nowadays we clearly see its limitations.  So please keep going
with this, and hopefully we will have a new display engine capable of
much more, and much better matching today's technologies and
expectations.

But saying that this can be done by just "drawing a vertical line" is
inaccurate at best.

> You are talking as if the complexity, quirks and limitations of Emacs'
> display engine were something good, something to be preserved, when it
> is quite the contrary, ever more when so few people understands it.

No, I'm saying that we shouldn't pretend we can implement features
like the one you mentioned without redesigning the display engine.
Just changing or replacing its terminal-specific backend will not be
enough.

Which is why replacing the toolkit(s) should have quite a different
perspective and different goals.

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Just to check your assertion, I tried to build Skia on my Debian box
> and, sure enough, after ten minutes of work the build succesfully
> completed. I had some issues that were swiftly solved with a web search.

Now try to link it with Emacs, enjoy the pages of linker errors, and get
frustrated two weeks later when the Skia developers change the signature
of some basic function causing the program to not work anymore.

That's been my experience working with Skia, and I think other people
will agree as well.

> A closer look at Skia makes me think that it is not a good candidate for
> Emacs, for several reasons. But Skia was just an example, we (or, better
> said, the OP) can examine what other options are available.

I would really appreciate names.

> We could turn the frame into a canvas. Take
> display-fill-column-indicator for instance. Instead of faking a line
> with characters, we could simply draw the line as a graphic object.

Alternatively, we could also ask RIF->draw_window_divider (which already
exists in every graphical port) to draw a line there.

It's just that nobody has put in the work to make that happen.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

IMHO something like Skia would be very overkill,
and damaging to Emacs' independence.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 25 Dec 2021 13:20:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> Why oh why you don't just say "go ahead and we will look at your work
> when you have something to show" ?

I did -- but that was before I understood what was being proposed.
The OP wanted assurance that the code will be accepted once done, and
I cannot in good faith give him that, given what's being actually
proposed.  Doing so would be betraying the OP's trust, especially if
eventually we don't like the results.

> > 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.
> 
> Yes, because having a single, modern, sane, popular cross-platform
> graphics library (let's say Skia, for instance) would make things much
> worse than the current status-quo, with N entangled backends requiring
> the participation of multiple experts every time a new feature is
> implemented :-/

That's not what on the table, AFAIU.

> To insist: the proposed system would have three characteristics:
> 
> 1. Cross-platform (as the proposal's subject says)
> 
> 2. Simplicity, compared to what we have now.
> 
> 3. New graphical capabilities that will make possible new high-level
>    features.
> 
> I don't know why you keep ignoring point 3, which is the most important,
> and reduce the proposal to "oh, someone wants to add one more graphical
> backend."

I'm not ignoring anything.  You, OTOH, ignore both what is being
proposed and the rest of the discussion.  In effect, you are talking
about an entirely different proposal, one about which I said it
_would_ make sense.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 15:37 by eliz@gnu.org:

> I did -- but that was before I understood what was being proposed.
> The OP wanted assurance that the code will be accepted once done,
> and I cannot in good faith give him that, given what's being actually
> proposed. Doing so would be betraying the OP's trust, especially if
> eventually we don't like the results.
> 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.

It would be extremely unfair to expect any sort of guarantee.  IMHO
only things required are plans and desire to have that sort of thing
inside the Emacs.  If the end result is disliked by the community,
it must not be included, and wait available for revisions.

See: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02203.html

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> Date: Sat, 25 Dec 2021 14:00:07 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, ofv@wanadoo.es
> 
> Dec 25, 2021, 15:37 by eliz@gnu.org:
> 
> > I did -- but that was before I understood what was being proposed.
> > The OP wanted assurance that the code will be accepted once done,
> > and I cannot in good faith give him that, given what's being actually
> > proposed. Doing so would be betraying the OP's trust, especially if
> > eventually we don't like the results.
> > 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.
> 
> It would be extremely unfair to expect any sort of guarantee.  IMHO
> only things required are plans and desire to have that sort of thing
> inside the Emacs.  If the end result is disliked by the community,
> it must not be included, and wait available for revisions.

No one needs anyone's permission to work on Emacs.  It is Free
Software.  If you want to work on it, you are most welcome, and none
of this discussion was necessary.  If this was due to my
misunderstanding, I again apologize.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 25, 2021, 16:05 by eliz@gnu.org:
> No one needs anyone's permission to work on Emacs. It is Free
> Software. If you want to work on it, you are most welcome, and none
> of this discussion was necessary. If this was due to my
> misunderstanding, I again apologize.

In my eyes there is nothing to apologize for, as maintainers are
already busy with a lot of things and cannot be expected to keep in
memory every single mail flying around.  A digest should be provided
to them after any detailed discussion.  (I also don't have the most
stable mind.  Apologies.)

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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.
>> 
>> Why oh why you don't just say "go ahead and we will look at your work
>> when you have something to show" ?
>
> I did -- but that was before I understood what was being proposed.
> The OP wanted assurance that the code will be accepted once done,

Oh, I missed that part. xenodasein: is that really what you want or is
there a misunderstanding here?

> and
> I cannot in good faith give him that, given what's being actually
> proposed.

Obviously you can't give that type of assurances for any proposal.

>> To insist: the proposed system would have three characteristics:
>> 
>> 1. Cross-platform (as the proposal's subject says)
>> 
>> 2. Simplicity, compared to what we have now.
>> 
>> 3. New graphical capabilities that will make possible new high-level
>>    features.
>> 
>> I don't know why you keep ignoring point 3, which is the most important,
>> and reduce the proposal to "oh, someone wants to add one more graphical
>> backend."
>
> I'm not ignoring anything.  You, OTOH, ignore both what is being
> proposed and the rest of the discussion.  In effect, you are talking
> about an entirely different proposal, one about which I said it
> _would_ make sense.

Well, maybe I'm thinking on what *I* would like to see instead on what
the OP is actually proposing.

xenodasein: would you say that my 3 points above fully describe your
proposal?

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

For my answer, see:

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02634.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02639.html

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Sorry for double mail.  I think we have exactly the same thing in mind:

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02628.html

Re: Platform independent graphical display for Emacs

[Po Lu]

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

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.

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.

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

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

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

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.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

We are not going to drop the X port.  Wayland is important, but it's
only available on a small amount of systems, certainly not all the
Unix-like systems currently support.

Other free systems such as FreeBSD immediately come to mind.

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

I too hope that, but a decade of Wayland development hasn't brought us
much in that direction.

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

I would welcome improvements to the Lucid toolkit.  Scaling is mostly
not the tookit's job under X, we just use GDK functions to get the
display's scale and apply that when creating the Cairo surface, AFAIU.

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

OpenGL is not practical for many things such as text rendering.  It is
also slow over X forwarding.

> This discussion started with a person expressing interest.

No, it started with a person saying that we should decide to adopt his
approach.  He did not volunteer to write it and do the work required to
integrate it with Emacs, I think.

Re: Platform independent graphical display for Emacs

[Dmitry Gutov]

On 25.12.2021 16:31, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> 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.
> 
> We are not going to drop the X port.  Wayland is important, but it's
> only available on a small amount of systems, certainly not all the
> Unix-like systems currently support.
> 
> Other free systems such as FreeBSD immediately come to mind.

PGTK still supports X. And supports well, AFAIK.

But with it becoming increasingly irrelevant over the coming decade, it 
should become more and more practical to drop the other ports. Though 
I'm sure we'll be reluctant to do that.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.12.2021 16:31, Po Lu wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> 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.
>> We are not going to drop the X port.  Wayland is important, but it's
>> only available on a small amount of systems, certainly not all the
>> Unix-like systems currently support.
>> Other free systems such as FreeBSD immediately come to mind.
>
> PGTK still supports X. And supports well, AFAIK.
>
> But with it becoming increasingly irrelevant over the coming decade,
> it should become more and more practical to drop the other ports.
> Though I'm sure we'll be reluctant to do that.

Yes.

Some people write here as if time doesn't exist, as if living in some
sort of static universe or on a pre-industrial age :-)

I would be surprised if the proposed system were ready to be released as
an experimental feature in less than 4 years. Add another 4 to stabilize
before it can be considered as a replacement for the legacy graphical
backends.

Re: Platform independent graphical display for Emacs

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> PGTK still supports X. And supports well, AFAIK.

It supports X with many fundamental limitations such as crashing when a
display is closed.  The quality of support GTK gives X is nowhere close
to the X port itself.

There are also several bugs that can't really be fixed, such as
bug#52737, bug#52655 and bug#52677.

> But with it becoming increasingly irrelevant over the coming decade,
> it should become more and more practical to drop the other
> ports.

I don't see it becoming "increasingly irrelevant".  The world is not
only the bleeding edge GNU/Linux systems, there are also older systems,
systems that don't have enough memory for compositing, people who don't
want to use Xwayland (face it, it still doesn't work right), and people
who have to run an X server on platforms such as MS-Windows or the other
free Unix variants.

Re: Platform independent graphical display for Emacs

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> I don't see it becoming "increasingly irrelevant".  The world is not
> only the bleeding edge GNU/Linux systems,

Your argument seems to suggest that it will still be relevant for some
time in certain configurations, not that it's relevance won't decrease.

Re: Platform independent graphical display for Emacs

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Your argument seems to suggest that it will still be relevant for some
> time in certain configurations, not that it's relevance won't
> decrease.

It'll always remain relevant enough for us to support.  Besides, 10
years is awfully optimistic for Wayland adoption.

People who want frame placement (i.e. by Speedbar) or session
restoration to work correctly will always have to run Emacs inside X (or
under Xwayland) as well, because even under Wayland X clients have the
ability to arbitrarily position windows.

Re: Platform independent graphical display for Emacs

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Dialogs are basically not very useful or Emacsy as is.  When they pop
> up, you are completely outside of "Emacs land", and there is no way for
> us to add keybindings, style them, etc. or do much of anything really.

Yeah, it's annoying.

> Our scrollbars are fairly subpar compared to the ones in VSCode, at
> least in GTK.  Admittedly that might be to some extent because it is
> hard to style them from Lisp themes (I guess that's not currently
> possible).

It's popular to switch them off, though.  😀

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

There's definitely different cultures surrounding the toolkit issue.
Some people want all their applications on the OS they use to look the
same, and some people want the application they use to look the same on
all OS-es.  I think the astounding success of VSCode points to the first
group of people putting up with it if they have to, but there's a lot of
grumbling.

Anyway, this inspired me to have a look at the no-toolkit build of Emacs
for the first time in years, and...  it's a bit rough.  There's no HiDPI
support, apparently, so all the icons/menus look unusably tiny on this
screen.  And the scroll bar apparently works the same as an xterm in
1989?  That is, left/right mouse clicks goes down/up, and you can't drag
it at all.

So it's no wonder that few people are using that.  But if want to cater
more to people that want Emacs to look the same on all operating
systems, there's at least a base to start working from, because it seems
to work fine otherwise.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Platform independent graphical display for Emacs

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And the scroll bar apparently works the same as an xterm in 1989?
> That is, left/right mouse clicks goes down/up, and you can't drag it
> at all.

You can drag it with mouse-2, just like in xterm -- in fact, it's
actually derived from the exact same scrollbar code that xterm used.

Re: Platform independent graphical display for Emacs

[Stephen Berman]

On Fri, 24 Dec 2021 10:55:03 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> There's definitely different cultures surrounding the toolkit issue.
> Some people want all their applications on the OS they use to look the
> same, and some people want the application they use to look the same on
> all OS-es.  I think the astounding success of VSCode points to the first
> group of people putting up with it if they have to, but there's a lot of
> grumbling.
>
> Anyway, this inspired me to have a look at the no-toolkit build of Emacs
> for the first time in years, and...  it's a bit rough.  There's no HiDPI
> support, apparently, so all the icons/menus look unusably tiny on this
> screen.  And the scroll bar apparently works the same as an xterm in
> 1989?  That is, left/right mouse clicks goes down/up, and you can't drag
> it at all.
>
> So it's no wonder that few people are using that.  But if want to cater
> more to people that want Emacs to look the same on all operating
> systems, there's at least a base to start working from, because it seems
> to work fine otherwise.

Perhaps the main issue keeping me from regularly using the no-toolkit
build is the inability to navigate menu-bar menus and select entries
from them with the keyboard (I disable the menu bar but not infrequently
pop up the global menu with F10).  If I had enough knowledge and time,
this would be one of the first things I would fix.

Steve Berman

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Ideally, in its final form this new system should reminiscent a simple
browser that runs Elisp instead of JS, with some level of drawing
capability.  It's functions will not be terminal compatible. It should
exist side-by-side with legacy (current) toolkit based GUI which is
already interoperable with text interface, for the foreseeable future.
(Text terminal will of course be forever.) Then there is the question
of which one is the default.

Or it could just be a toolkit=no on steroids.  Very open to discussion.

It could start developing as the latter, in time evolving into the
former, or we could design it as a completely new GUI from beginning.
This is also about reducing non-gnu linked libraries to a minimum and
reinventing relatively easy to reinvent things inside Emacs. As long
as it reduces maintenance burden compared to linking with something,
reducing the damage to Emacs to minimum from things like X/Wayland
split, or GNOME mess.

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> As long as it reduces maintenance burden compared to linking with
> something, reducing the damage to Emacs to minimum from things like
> X/Wayland split, or GNOME mess.

It will mean we will have to deal with Wayland directly, which is much,
much more complicated than letting GTK do it for us.

That's not the case with X, but it is for Wayland.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 14:07 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> As long as it reduces maintenance burden compared to linking with
>> something, reducing the damage to Emacs to minimum from things like
>> X/Wayland split, or GNOME mess.
>>
>
> It will mean we will have to deal with Wayland directly, which is much,
> much more complicated than letting GTK do it for us.
>
> That's not the case with X, but it is for Wayland.
>

Something to consider.  I forgot to emphasis being cross-platform,
would it play well?

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Something to consider.  I forgot to emphasis being cross-platform,
> would it play well?

What do you mean by "it" here?

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 14:31 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Something to consider.  I forgot to emphasis being cross-platform,
>> would it play well?
>>
>
> What do you mean by "it" here?
>

GTK.  It looked intrusive to me, while making things easier on Wayland
would it also make things harder on other places?  Especially if it is
not available.

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> GTK. It looked intrusive to me, while making things easier on Wayland
> would it also make things harder on other places? Especially if it is
> not available.

We don't use GTK where it's not available, and use of GTK will always
stay optional, so I don't understand what you're trying to say.

Anyway, using GTK for Wayland support doesn't affect what we do
elsewhere.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 15:08 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> GTK. It looked intrusive to me, while making things easier on Wayland
>> would it also make things harder on other places? Especially if it is
>> not available.
>>
>
> We don't use GTK where it's not available, and use of GTK will always
> stay optional, so I don't understand what you're trying to say.
>
Optional?  What I understood from you that it would be the only
connection between Emacs and Wayland in the new system, to avoid
dealing with the Wayland directly.

> Anyway, using GTK for Wayland support doesn't affect what we do
> elsewhere.
>
Surely intrusive, event-driven libs like GTK necessitate changes in our
code, which are otherwise unnecessary complexity elsewhere, when
GTK isn't even used?

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Optional?  What I understood from you that it would be the only
> connection between Emacs and Wayland in the new system, to avoid
> dealing with the Wayland directly.

Yes, but we will not run only on Wayland.  Besides, I wasn't talking
about a "new system", I was referring to what we have now as the PGTK
port.

> Surely intrusive, event-driven libs like GTK necessitate changes in
> our code, which are otherwise unnecessary complexity elsewhere, when
> GTK isn't even used?

Being "event-driven" is hardly why GTK is problematic.  A small file
named xgselect.c takes care of the GLib event loop with some clever
code, so we don't have to worry about it anywhere else.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Dec 24, 2021, 15:27 by luangruo@yahoo.com:

>> Surely intrusive, event-driven libs like GTK necessitate changes in
>> our code, which are otherwise unnecessary complexity elsewhere, when
>> GTK isn't even used?
>>
>
> Being "event-driven" is hardly why GTK is problematic.  A small file
> named xgselect.c takes care of the GLib event loop with some clever
> code, so we don't have to worry about it anywhere else.
>

I grepped a bit, and there many conditional modifications to frame
related functions through #ifdef USE_GTK.  This doesn't bode well for
a cross-platform frame logic, IMO.  Is this what you referred to as
problematic?

Re: Platform independent graphical display for Emacs

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I grepped a bit, and there many conditional modifications to frame
> related functions through #ifdef USE_GTK.  This doesn't bode well for
> a cross-platform frame logic, IMO.  Is this what you referred to as
> problematic?

That's only the tip of the iceberg, but is completely unrelated to event
handling, where the relevant conditional is `HAVE_GLIB'.

The problem could be easily resolved if the GTK+ developers actually
paid attention to our reasonable requests, but they refuse to do so
because Emacs is, in their opinion, not a well-behaved program.

Case in point: the nearly 20-year old GTK bug where GTK aborts when a
display is closed.  We used to longjmp out, but that used to cause GLib
to emit a large amount of warnings, so that workaround was turned off,
and doesn't work nowadays either.

Another case in point: try resizing or creating a frame on a GTK build
that is smaller than its menu bar, see what GTK does to it, and compare
that behaviour (which cannot be turned off, at least when I tried) to
the behaviour under an Xt or no-toolkit build.

Then of course, there are the many other instances where the GTK
developers refused to implement a basic feature, such as the ability to
adjust the thumb size of a scrollbar, because they did not think it fit
with their idea of how a program should behave appearance-wise.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02557.html
From: Po Lu

> That's only the tip of the iceberg...

Wow, saving this mail.  Thanks.

This is just my $0.02 when it comes to some new system.

It is very valid to work only towards improving Emacs in its current
form without fundamental changes, making it a more pleasant experience
for the stable user base.  Especially for people who aren't into
programming, and can't be expected to fix their environmental all the
time.  Making fundamental changes to expand user base is the risky move
and what would be the gain apart from ideological significance; bragging
rights?

If it is to be done though, new things must be tried. A "Do. Or do not.
There is no try." situation if you will.

Like ditching GTK altogether.  Maybe it will instead attract contributors
that value knowing what goes under the hood, and would much rather
spend time with documentation of Wayland?  Passion for computing
is the common ground for Emacs users after all.

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > Another case in point: try resizing or creating a frame on a GTK build
 > that is smaller than its menu bar, see what GTK does to it, and compare
 > that behaviour (which cannot be turned off, at least when I tried) to
 > the behaviour under an Xt or no-toolkit build.

What precisely is the problem with the menu bar?

Here it is problematic to shrink the width of a frame to some size less
than that required for the tool bar.  But that's moot currently given
the fact that my tool bar icons have so far inexplicably vanished from
all GTK frames on Debian bullseye and I get only plain text instead of
them.

martin

Re: Platform independent graphical display for Emacs

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

> Here it is problematic to shrink the width of a frame to some size
> less than that required for the tool bar.  But that's moot currently
> given the fact that my tool bar icons have so far inexplicably
> vanished from all GTK frames on Debian bullseye and I get only plain
> text instead of them.

That too, but the menu bar does the same thing as the toolbar.  Also try
running with x-gtk-stock-map set to nil, and x-gtk-stock-cache set to an
empty hash table, to see if the icons come back.

Thanks.

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > That too, but the menu bar does the same thing as the toolbar.

My memory is failing.  I even menitoned that in PROBLEMS.

BTW - the pgtk build seems to refuse shrinking a frame via mouse
dragging in such case.  The gtk build apparently doesn't.

 > Also try
 > running with x-gtk-stock-map set to nil, and x-gtk-stock-cache set to an
 > empty hash table, to see if the icons come back.

Thanks.  I will look into them next time I'm on that machine.

martin

Re: Platform independent graphical display for Emacs

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

> BTW - the pgtk build seems to refuse shrinking a frame via mouse
> dragging in such case.  The gtk build apparently doesn't.

I think that boils down to the regular GTK build receiving
ConfigureNotify before GTK does (and runs its size allocation
machinery), while with the PGTK build GTK receives it and can do its
thing first.

I might be able to solve this.

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > Also try
 > running with x-gtk-stock-map set to nil, and x-gtk-stock-cache set to an
 > empty hash table, to see if the icons come back.

I tried all these with no avail.  This behavior seems systemic to my GTK
setup on that machine.  I still have to investigate whether the fact
that the toolbar item text is shown instead (and not some graphical
artifact indicating the absence of the requested icon) is in some way
indicative.

martin

Re: Platform independent graphical display for Emacs

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

> I tried all these with no avail.  This behavior seems systemic to my
> GTK setup on that machine.

Then I have no idea what is going on, unfortunately.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But if want to cater
> more to people that want Emacs to look the same on all operating
> systems, there's at least a base to start working from, because it seems
> to work fine otherwise.

I don't use the platform's dialogs (they are a joke compared to what
Emacs provides) and can switch from Emacs-lucid on GNU/Linux to Emacs on
MS-Windows without perceptible psychic trauma. Well, actually, without
noticing.

About those people wanting Emacs to look "platform-native" (1):

If a new display backend makes possible new features which enhances
productivity (or even just aesthetics) it is reasonable to expect that
some of them will accept the change as a good trade-off. Furthermore, it
hopefully will attract new users which will provide an even stronger
stream of complaints on future changes.

And you can't keep everyone happy all the time. We all know that the
slightest change on Emacs upsets someone, somewhere. This would be a
reason to stop development. But then the absence of change on Emacs also
upsets other people, so... you can't keep everyone happy all the time.

1: What is "platform-native" varies with each new major release of GTK
   and Windows.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 24 Dec 2021 12:45:56 +0100
> 
> 1: What is "platform-native" varies with each new major release of GTK
>    and Windows.

But it changes for all the GUI applications, not just for Emacs.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1: What is "platform-native" varies with each new major release of GTK
>>    and Windows.
>
> But it changes for all the GUI applications, not just for Emacs.

Which means that they value consistency with other applications that
follow the platform standard.

However, Emacs is already largely deviant from the platform's UI. On
MS-Windows, things like customize-variable shows an interface which has
nothing to do with the platform's standard GUI widgets. It seems that
the only elements which are "native" in the MS-Windows port are the menu
and the dialogs.

If we add to that that Emacs has its own way of doing things (M-x
command system, interaction through the minibuffer instead of dialogs,
different keyboard shorcuts for standard actions like cut&paste, etc.)
we could conclude that Emacs already is very alien to
MS-Windows/GTK/MacOS UI standards.

So I can hardly imagine a typical Emacs user that could make a big issue
about the menus or dialogs being a bit different from what his
platform's standard ones are, as long as the replacement is not ugly
("ugly" in the sense the motif menu is ugly compared to Lucid and GTK.)

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> So I can hardly imagine a typical Emacs user that could make a big
> issue about the menus or dialogs being a bit different from what his
> platform's standard ones are, as long as the replacement is not ugly
> ("ugly" in the sense the motif menu is ugly compared to Lucid and
> GTK.)

The Lucid menu was mostly designed after the Motif menu.  They also look
mostly identical.  Anyway, the reason support for those toolkits was
added is that people care for them, and that's also why nobody uses the
no-toolkit build anymore.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So I can hardly imagine a typical Emacs user that could make a big
>> issue about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and
>> GTK.)
>
> The Lucid menu was mostly designed after the Motif menu.  They also look
> mostly identical.

No, the Lucid menu here shows a nice, modern font, while the Motif menu
shows some pixelated thing from the eighties.

> Anyway, the reason support for those toolkits was
> added is that people care for them,

I'm sure that at some point the motif port was appreciated as an
improvement. I tried it when you reinstated the configure option, and it
was like going back 30 years. I saw no reason to prefer it to what I use
(Lucid), quite the contrary.

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> No, the Lucid menu here shows a nice, modern font, while the Motif
> menu shows some pixelated thing from the eighties.

Your version of Motif is either too old to support Xft, or your system
is incorrectly configured.

Try adding the following resources to your X server:

  *.renderTable: variable
  *.renderTable.variable.fontName: Sans
  *.renderTable.variable.fontSize: 8
  *.renderTable.variable.fontType: FONT_IS_XFT

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> No, the Lucid menu here shows a nice, modern font, while the Motif
>> menu shows some pixelated thing from the eighties.
>
> Your version of Motif is either too old to support Xft, or your system
> is incorrectly configured.

I'm using Debian Testing.

> Try adding the following resources to your X server:
>
>   *.renderTable: variable
>   *.renderTable.variable.fontName: Sans
>   *.renderTable.variable.fontSize: 8
>   *.renderTable.variable.fontType: FONT_IS_XFT

No, I don't need to tinker with configuration files for any other app to
look good and I wont start doing it for something that offers no benefit
over what I already use.

Re: Platform independent graphical display for Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Your version of Motif is either too old to support Xft, or your system
>> is incorrectly configured.

> I'm using Debian Testing.

That doesn't tell if your Motif is installed correctly with the
appropriate build options.

>> Try adding the following resources to your X server:
>>
>>   *.renderTable: variable
>>   *.renderTable.variable.fontName: Sans
>>   *.renderTable.variable.fontSize: 8
>>   *.renderTable.variable.fontType: FONT_IS_XFT

> No, I don't need to tinker with configuration files for any other app to
> look good and I wont start doing it for something that offers no benefit
> over what I already use.

If you aren't interested, then I suggest you ignore the problem: Motif
users will use CDE, which configures Motif properly by default, or have
their system configured to suit them.

Similarly, you will get Courier drawn through Core Fonts if you build
the Lucid toolkit without Xft or Cairo support.

Re: Platform independent graphical display for Emacs

[Jose A. Ortega Ruiz]

On Fri, Dec 24 2021, Po Lu wrote:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So I can hardly imagine a typical Emacs user that could make a big
>> issue about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and
>> GTK.)
>
> The Lucid menu was mostly designed after the Motif menu.  They also look
> mostly identical.  Anyway, the reason support for those toolkits was
> added is that people care for them, and that's also why nobody uses the
> no-toolkit build anymore.

i use it.  and have been using it for the last 20 years.  i want an
emacs with graphical capabilities but i don't use any toolkit element
ever.

i wish you'd be as nice with the non-toolikit option as you've been with
the motif one, if possible.

thanks,
jao
-- 
There are no whole truths; all truths are half-truths. It is trying to
treat them as whole truths that plays the devil. -Alfred Whitehead

Re: Platform independent graphical display for Emacs

[Po Lu]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> i use it.  and have been using it for the last 20 years.  i want an
> emacs with graphical capabilities but i don't use any toolkit element
> ever.
>
> i wish you'd be as nice with the non-toolikit option as you've been
> with the motif one, if possible.

I don't know how to improve the no-toolkit build.  Feel free to work on
that, however.

Thanks.

Re: Platform independent graphical display for Emacs

[Jose Antonio Ortega Ruiz]

On Sat, Dec 25 2021, Po Lu wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> i use it.  and have been using it for the last 20 years.  i want an
>> emacs with graphical capabilities but i don't use any toolkit element
>> ever.
>>
>> i wish you'd be as nice with the non-toolikit option as you've been
>> with the motif one, if possible.
>
> I don't know how to improve the no-toolkit build.  Feel free to work on
> that, however.

i don't need any improvement.  i'll be content if it doesn't disappear
under the false premise that "nobody uses it".

thanks,
jao
-- 
It does not do to leave a live dragon out of your calculations, if you
live near him. -J.R.R. Tolkien, novelist and philologist (1892-1973)

Re: Platform independent graphical display for Emacs

[Po Lu]

Jose Antonio Ortega Ruiz <jao@gnu.org> writes:

> i don't need any improvement.  i'll be content if it doesn't disappear
> under the false premise that "nobody uses it".

It will not disappear as it adds no extra complexity to maintainence,
and it is also important at least for testing purposes.

For example, it was very helpful during the development of the XInput 2
support, before I managed to make it work with GTK+.

Thanks.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Jose Antonio Ortega Ruiz <jao@gnu.org>
> Date: Sat, 25 Dec 2021 05:12:18 +0000
> Cc: emacs-devel@gnu.org
> 
> > I don't know how to improve the no-toolkit build.  Feel free to work on
> > that, however.
> 
> i don't need any improvement.  i'll be content if it doesn't disappear
> under the false premise that "nobody uses it".

It won't, don't worry.  The no-toolkit build is the basis for
everything else, so it should be always available.

Re: Platform independent graphical display for Emacs

[martin rudalics]

 > I don't know how to improve the no-toolkit build.  Feel free to work on
 > that, however.

It lacks horizontal scroll bars.  It should be easy to do, yet I never
finished that code.

martin

Re: Platform independent graphical display for Emacs

[LdBeth]

>>>>> In <87lf09gye1.fsf@gnus.jao.io> 
>>>>>	"Jose A. Ortega Ruiz" <jao@gnu.org> wrote:
jao> On Fri, Dec 24 2021, Po Lu wrote:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So I can hardly imagine a typical Emacs user that could make a big
>> issue about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and
>> GTK.)
>
> The Lucid menu was mostly designed after the Motif menu.  They also look
> mostly identical.  Anyway, the reason support for those toolkits was
> added is that people care for them, and that's also why nobody uses the
> no-toolkit build anymore.

jao> i use it.  and have been using it for the last 20 years.  i want an
jao> emacs with graphical capabilities but i don't use any toolkit element
jao> ever.

jao> i wish you'd be as nice with the non-toolikit option as you've been with
jao> the motif one, if possible.

jao> thanks,
jao> jao
jao> -- 
jao> There are no whole truths; all truths are half-truths. It is trying to
jao> treat them as whole truths that plays the devil. -Alfred Whitehead

Same situtation here. I'm using Emacs on a nearly 20 years old laptop
with Gentoo Linux. I don't use any other GUI programs other than Emacs
and a terminal emulator, nor any GUI toolkit element for Emacs.  It's
just I don't like to compile and install GTK for solely a GUI build of
Emacs.

Please continue to keeps the non-toolikit option, or at least consider
using a light weight toolkit. Thanks.
-- 
LDB

Re: Platform independent graphical display for Emacs

[Po Lu]

LdBeth <andpuke@foxmail.com> writes:

> Please continue to keeps the non-toolikit option, or at least consider
> using a light weight toolkit. Thanks.

We are not (and hopefully never) going to remove the no-toolkit build.

While I said that support for Motif was added because people cared for
it, I didn't say that we would remove features like the no-toolkit
build, which I think very little people really care for.

OTOH, both Motif and lwlib/Athena are relatively lightweight (compared
to GTK+) and will probably serve you just as well as the no-toolkit
build for your purposes.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 24 Dec 2021 14:19:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1: What is "platform-native" varies with each new major release of GTK
> >>    and Windows.
> >
> > But it changes for all the GUI applications, not just for Emacs.
> 
> Which means that they value consistency with other applications that
> follow the platform standard.
> 
> However, Emacs is already largely deviant from the platform's UI. On
> MS-Windows, things like customize-variable shows an interface which has
> nothing to do with the platform's standard GUI widgets.

Isn't that so on other platforms as well?  Wherever Emacs invented its
own UI, that UI and its widgets will always be different from the
platform standards.

> It seems that the only elements which are "native" in the MS-Windows
> port are the menu and the dialogs.

And the scroll bars.  And the frame decorations.

Is that different from other toolkits?  OK, so with GTK we also use
their tool bar and tooltips (and get to live with their limitations),
but other than that?

> If we add to that that Emacs has its own way of doing things (M-x
> command system, interaction through the minibuffer instead of dialogs,
> different keyboard shorcuts for standard actions like cut&paste, etc.)
> we could conclude that Emacs already is very alien to
> MS-Windows/GTK/MacOS UI standards.

That's an exaggeration.

> So I can hardly imagine a typical Emacs user that could make a big issue
> about the menus or dialogs being a bit different from what his
> platform's standard ones are, as long as the replacement is not ugly
> ("ugly" in the sense the motif menu is ugly compared to Lucid and GTK.)

That's an "ad absurdum" kind of argument.

In general, Emacs does do some (quite a few) thing differently, and
where it does, it does so uniformly on all platforms, more or less (I
think NS is the largest outlier here, with its Cmd key).  But this is
a tangent: we weren't discussing the entire UI and its conventions, we
only discussed the GUI aspects of the Emacs appearance.

Re: Platform independent graphical display for Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> However, Emacs is already largely deviant from the platform's UI. On
>> MS-Windows, things like customize-variable shows an interface which has
>> nothing to do with the platform's standard GUI widgets.
>
> Isn't that so on other platforms as well?

Sure.

> Wherever Emacs invented its own UI, that UI and its widgets will
> always be different from the platform standards.

Yes, so deviating a bit more from the platform's UI shouldn't be a
problem as long as it provides some advantage.

>> It seems that the only elements which are "native" in the MS-Windows
>> port are the menu and the dialogs.
>
> And the scroll bars.

Yep, forgot those. Maybe because I use different versions of MS-Windows
and the scroll bars look different on each.

> And the frame decorations.

The frame decorations usually are provided by the Window Manager, they
are not something which are under Emacs' control (although MS-Windows
allows to change them to a large extent, other systems do not.)

> Is that different from other toolkits?  OK, so with GTK we also use
> their tool bar and tooltips (and get to live with their limitations),
> but other than that?
>
>> If we add to that that Emacs has its own way of doing things (M-x
>> command system, interaction through the minibuffer instead of dialogs,
>> different keyboard shorcuts for standard actions like cut&paste, etc.)
>> we could conclude that Emacs already is very alien to
>> MS-Windows/GTK/MacOS UI standards.
>
> That's an exaggeration.

Well, that's your opinion about my perception ;-) I still remember very
well when I learned Emacs 20 years ago. It was otherworldly to me.
Neither then (when I was using MS-Windows only) nor now (when I'm
primarly a GNU/Linux user) there is anything that is vaguely similar to
Emacs on the set of applications used by the people I know.

>> So I can hardly imagine a typical Emacs user that could make a big issue
>> about the menus or dialogs being a bit different from what his
>> platform's standard ones are, as long as the replacement is not ugly
>> ("ugly" in the sense the motif menu is ugly compared to Lucid and GTK.)
>
> That's an "ad absurdum" kind of argument.
>
> In general, Emacs does do some (quite a few) thing differently, and
> where it does, it does so uniformly on all platforms, more or less (I
> think NS is the largest outlier here, with its Cmd key).  But this is
> a tangent: we weren't discussing the entire UI and its conventions, we
> only discussed the GUI aspects of the Emacs appearance.

I'm discussing the GUI too, but both the xenodasein and me are not
concerned with putting some lipstick on top of current Emacs GUI. IIUC
the change he is proposing is directed towards simplyfing the GUI code
*and* expanding what we can show, which would set the basis for a whole
lot of new features.

Re: Platform independent graphical display for Emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 24 Dec 2021 10:55:03 +0100
> Cc: Po Lu <luangruo@yahoo.com>, Drew Adams <drew.adams@oracle.com>,
>  "xenodasein--- via Emacs development discussions." <emacs-devel@gnu.org>
> 
> Anyway, this inspired me to have a look at the no-toolkit build of Emacs
> for the first time in years, and...  it's a bit rough.  There's no HiDPI
> support, apparently, so all the icons/menus look unusably tiny on this
> screen.  And the scroll bar apparently works the same as an xterm in
> 1989?  That is, left/right mouse clicks goes down/up, and you can't drag
> it at all.

That's no surprise: no one develops that configuration since it
exists.  So it's a kind-of vicious circle: this configuration doesn't
get any love because no one likes it, and no one likes it because it
doesn't get any love.

> So it's no wonder that few people are using that.  But if want to cater
> more to people that want Emacs to look the same on all operating
> systems, there's at least a base to start working from, because it seems
> to work fine otherwise.

Please note that the code still is full of Xlib calls, so making it
work on other systems will not be trivial.

Re: Platform independent graphical display for Emacs

[xenodasein--- via Emacs development discussions.]

FWIW, a lot of conversation seem to happen in this line of thread that
have wrong judgment on what is being suggested.  It may not be
complete or perfectly clear, but already contradicts some of things
written after it.

Please see:

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02539.html
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02574.html

Re: Motif support

[Eli Zaretskii]

> Date: Fri, 24 Dec 2021 02:17:32 +0100 (CET)
> Cc: emacs-devel@gnu.org
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> You kinda have to use platform dependent features directly, as we
> are not programming into aether.  However, painting menus isn't one.
> You don't need a third-party solution, whether it is from platform itself
> like legacy win32 GUI elements or another library.  Using them is like
> using a sledgehammer to drive a nail in Emacs' case. We could even do
> the text rendering itself too, provided an expert would contribute it to
> Emacs.  But no one said let's do text rendering, AFAIK.

But we already have all that -- that's the X build without any
toolkits.  Almost no one uses it, because any toolkit version looks
much nicer, so we can conclude today what would be the result of your
suggestions.  Producing a good-looking GUI application is a lot of
low-level work, and suggesting that we do all or most of that "by
hand" is really a non-starter.

Re: Motif support

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Anyway, I find this discusion with you immature. You are sitting here
> and trying to find anything opposite for the sake of sake of saying
> opposite. Sorry, all best to you, I wish you Merry Christmass and all
> best, but I am out.

Merry Christmas.

You'll notice that I was not trying to find "anything opposite", but
mostly sticking to the same points, which a cursory inspection of the
existing FreeType-based font drivers (and also why it's "drivers" and
not "driver") will confirm.

Thanks.

Re: Motif support

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02250.html
From: Eli Zaretskii

> >>> Games usually do all GUI drawing themselves.
> >> So you are saying that so should we??
>
> > Believe it or not, Emacs is much more reminiscent of a game engine than
> > a desktop app.

> I indeed don't believe it.

Do you say this having used and inspected the source code of multiple
relatively recent game engines?  If that is the case, an elaboration
from someone of your experience level would be valuable.

Re: Motif support

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 16:05:12 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, arthur.miller@live.com, ofv@wanadoo.es
> 
> > > Believe it or not, Emacs is much more reminiscent of a game engine than
> > > a desktop app.
> 
> > I indeed don't believe it.
> 
> Do you say this having used and inspected the source code of multiple
> relatively recent game engines?  If that is the case, an elaboration
> from someone of your experience level would be valuable.

I'm saying this as someone who is familiar with the Emacs display
code.