Abysmal state of GTK build

Abysmal state of GTK build

[Po Lu]

Users of the GTK 3 build experience many, many problems.  The most
recent such problem is bug#56869, which is definitely a bug in GTK.

Taking into account the very low quality of the GDK X11 backend, which
is not seeing active maintenance, shouldn't the build default to some
other toolkit such as Motif, or even better, no toolkit at all?

Especially considering that a GTK developer (the tail) wants to remove
support for X11 (the dog) in future releases of GTK:

  https://gitlab.gnome.org/GNOME/gtk/-/issues/5004

Re: Abysmal state of GTK build

[Dmitry Gutov]

On 21.08.2022 14:04, Po Lu wrote:
> Users of the GTK 3 build experience many, many problems.  The most
> recent such problem is bug#56869, which is definitely a bug in GTK.

Is that a new state of affairs, caused by newer GTK version or changes 
in Emacs?

If not, the GTK3 build has been pretty stable for a lot of us, so 
there's no point in deprecating it over an unusual use case. Or even a 
bunch of them.

Re: Abysmal state of GTK build

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Is that a new state of affairs, caused by newer GTK version or changes
> in Emacs?

The bug at hand is a new state of affairs caused by the Emacs migration
to XInput 2, which has exposed new bugs in GTK.  In general, however,
GTK support for X11 has become steadily worse since 3.4.

> If not, the GTK3 build has been pretty stable for a lot of us, so
> there's no point in deprecating it over an unusual use case. Or even a
> bunch of them.

It's not being deprecated, just being demoted from the default.
Disabling the trackpad while typing is hardly an "unusual" use-case, and
even comes enabled by default on many systems.

Re: Abysmal state of GTK build

[Dmitry Gutov]

[-- Attachment #1: Type: text/html, Size: 1255 bytes --]

Re: Abysmal state of GTK build

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> So it's the result of new code in Emacs, I take it.

Which is still a problem with GTK, because it uses XInput 2.  It was
previously disabled, preventing us from handling touchscreen and
high-resolution scrolling events.

>  It's not being deprecated, just being demoted from the default.
>  Disabling the trackpad while typing is hardly an "unusual" use-case, and
>  even comes enabled by default on many systems.
>
> I think it's the default on mine, too. Should I have noticed the problem?

I don't know.  It's a race condition.

Re: Abysmal state of GTK build

[Gregory Heytings]

>> So it's the result of new code in Emacs, I take it.
>
> Which is still a problem with GTK, because it uses XInput 2.  It was 
> previously disabled, preventing us from handling touchscreen and 
> high-resolution scrolling events.
>

If so, is it not possible to simply tell users that touchscreen and 
high-resolution scrolling events are disabled in GTK builds, and let them 
choose between Lucid build in which these events are supported and a GTK 
build in which they aren't?

Re: Abysmal state of GTK build

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> If so, is it not possible to simply tell users that touchscreen and
> high-resolution scrolling events are disabled in GTK builds, and let
> them choose between Lucid build in which these events are supported
> and a GTK build in which they aren't?

If it will be missing such important features, then GTK support should
be demoted from the default.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Sun, 21 Aug 2022 19:04:01 +0800
> 
> Users of the GTK 3 build experience many, many problems.  The most
> recent such problem is bug#56869, which is definitely a bug in GTK.
> 
> Taking into account the very low quality of the GDK X11 backend, which
> is not seeing active maintenance, shouldn't the build default to some
> other toolkit such as Motif, or even better, no toolkit at all?

Why not Lucid?

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Why not Lucid?

I forgot to include that, sorry.  I meant it along with the Motif build,
since both work equally well.  Several months ago only the Motif build
was usable under XInput 2, but all of those bugs were eliminated between
then and now.

Re: Abysmal state of GTK build

[Robert Pluim]

>>>>> On Sun, 21 Aug 2022 19:39:34 +0800, Po Lu <luangruo@yahoo.com> said:

    Po Lu> Eli Zaretskii <eliz@gnu.org> writes:
    >> Why not Lucid?

    Po Lu> I forgot to include that, sorry.  I meant it along with the Motif build,
    Po Lu> since both work equally well.  Several months ago only the Motif build
    Po Lu> was usable under XInput 2, but all of those bugs were eliminated between
    Po Lu> then and now.

There was a time when I was young and naïve, and thought that GTK was
going to be the answer to Emacsʼ toolkit issues. That has turned out
to be somewhat untrue [1], so perhaps we should default to Lucid (itʼs
still pretty ugly, but I donʼt use menus or scrollbars so that doesnʼt
affect me personally). If Someone™ contributes a Qt port, that might
do as well (there was a port of XEmacs to Qt several decades ago, so
it definitely feasible).

Robert

Footnotes:
[1] Thatʼs an understatement. GTK has turned into a total clusterfuck.

-- 

Re: Abysmal state of GTK build

[Sean Whitton]

Hello,

On Sun 21 Aug 2022 at 05:54PM +02, Robert Pluim wrote:

> If Someone™ contributes a Qt port, that might
> do as well (there was a port of XEmacs to Qt several decades ago, so
> it definitely feasible).

That would also get us another native Wayland backend, and probably one
that would could more heartily recommend to people.

-- 
Sean Whitton

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> That would also get us another native Wayland backend, and probably one
> that would could more heartily recommend to people.

That'd be nice -- but do we have any concrete reason to believe that Qt
is going to suck less than Gtk?  Everybody has a tendency to think that
something like this must surely be great -- until they start actually
working with it, and then they discover all the things that just doesn't
work (as we found out with Gtk, but only after a few years of actually
working with it).

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That'd be nice -- but do we have any concrete reason to believe that Qt
> is going to suck less than Gtk?

(That came off as a rhetorical question -- but it was a genuine
question.  😀)

Re: Abysmal state of GTK build

[Sean Whitton]

Hello,

On Sun 21 Aug 2022 at 06:46PM +02, Lars Ingebrigtsen wrote:

>
> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> That would also get us another native Wayland backend, and probably one
>> that would could more heartily recommend to people.
>
> That'd be nice -- but do we have any concrete reason to believe that Qt
> is going to suck less than Gtk?  Everybody has a tendency to think that
> something like this must surely be great -- until they start actually
> working with it, and then they discover all the things that just doesn't
> work (as we found out with Gtk, but only after a few years of actually
> working with it).

Right.  Hopefully someone who already had the background knowledge to
implement a Qt build would be able to tell us why or why not.

-- 
Sean Whitton

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That'd be nice -- but do we have any concrete reason to believe that Qt
> is going to suck less than Gtk?  Everybody has a tendency to think that
> something like this must surely be great -- until they start actually
> working with it, and then they discover all the things that just doesn't
> work (as we found out with Gtk, but only after a few years of actually
> working with it).

I don't know.  I guess we will only find out once someone starts writing
such a port.

GTK was fine at first (I remember the scroll bar flickering being an
issue in the early days of the GTK+ build), but due to the bad decisions
of the GNOME developers, has been getting steadily worse since 3.0, and
even more so since 3.4.

Re: Abysmal state of GTK build

[tomas]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Mon, Aug 22, 2022 at 09:13:18AM +0800, Po Lu wrote:

[...]

> GTK was fine at first (I remember the scroll bar flickering being an
> issue in the early days of the GTK+ build), but due to the bad decisions
> of the GNOME developers, has been getting steadily worse since 3.0, and
> even more so since 3.4.

Indeed, I still compile my Emacs against Gtk2, it seems to be a sweet
spot. The day that falls by the wayside, I'll probably fall back to
Lucid or something.

Cheers (and thanks for all your hard work!)
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > GTK was fine at first (I remember the scroll bar flickering being an
  > issue in the early days of the GTK+ build), but due to the bad decisions
  > of the GNOME developers, has been getting steadily worse since 3.0, and
  > even more so since 3.4.

Can we develop our port to work with GTK version 2?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Can we develop our port to work with GTK version 2?

It already does, but GTK 2 is obsolete and will no longer be available
on most systems in the near future.

Re: Abysmal state of GTK build

[tomas]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Tue, Aug 23, 2022 at 11:58:01AM +0800, Po Lu wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> > Can we develop our port to work with GTK version 2?
> 
> It already does, but GTK 2 is obsolete and will no longer be available
> on most systems in the near future.

Yes, currently I build "my" Emacs with GTK2. It works nicely. I'll return
to Lucid when GTK2 falls off the distro. Not without complaining loudly,
mind you (at the distro, not at Emacs :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Abysmal state of GTK build

[Óscar Fuentes]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Sun 21 Aug 2022 at 05:54PM +02, Robert Pluim wrote:
>
>> If Someone™ contributes a Qt port, that might
>> do as well (there was a port of XEmacs to Qt several decades ago, so
>> it definitely feasible).
>
> That would also get us another native Wayland backend, and probably one
> that would could more heartily recommend to people.

Emacs tends to do things on its specific way. Big fat frameworks like
GTK and (even worse AFAIK) Qt provide high-level APIs and don't work
very well when the user needs to deviate from them.

Long time ago I proposed to investigate the feasibility of a Qt backend,
which was a not very welcomed because it would entail C++ and... Qt. Rigth
now I'll rather pick some low-level GUI library and build on top of it.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 21 Aug 2022 18:51:17 +0200
> 
> now I'll rather pick some low-level GUI library and build on top of it.

Any candidates you could mention?

Re: Abysmal state of GTK build

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> now I'll rather pick some low-level GUI library and build on top of
>> it.
>
> Any candidates you could mention?

One possibility is some tiny GUI library of the type of Nuklear, Dear
Imgui, etc. Those have the inconvenience of belonging to the "immediate"
paradigm (they generate the contents of the window and paint them lots
of times per second, as games do) which can cause significant CPU
overhead if the cache mechanisms for not regenerating/repainting
non-changing areas are not used effectively.

Then we have Skia and Cairo, which "simply" provide surfaces to paint
on. IIRC Po said that is not happy with the later.

Finally, SDL is somewhere on the middle.

Using libraries intended for games is not as bizarre as it sounds,
because Emacs' architecture is more similar to a video game than to a
conventional desktop application.

Re: Abysmal state of GTK build

[Po Lu]

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

> Emacs tends to do things on its specific way. Big fat frameworks like
> GTK and (even worse AFAIK) Qt provide high-level APIs and don't work
> very well when the user needs to deviate from them.

The only "low-level API" used by Emacs is Xlib.  On every other
platform, high level APIs are used.  On the Haiku port, each window's
event loop runs in its own thread, and events are simply serialized and
sent down a big pipe, where it is then read by haiku_read_socket.

> Long time ago I proposed to investigate the feasibility of a Qt backend,
> which was a not very welcomed because it would entail C++ and... Qt. Rigth
> now I'll rather pick some low-level GUI library and build on top of it.

What's wrong with C++ in GUI code?  See src/haiku_support.cc.
Please feel free to work on a Qt port using that as reference.

Re: Abysmal state of GTK build

[Stefan Monnier]

> The only "low-level API" used by Emacs is Xlib.  On every other
> platform, high level APIs are used.  On the Haiku port, each window's
> event loop runs in its own thread, and events are simply serialized and
> sent down a big pipe, where it is then read by haiku_read_socket.

Makes a lot of sense.


        Stefan

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What's wrong with C++ in GUI code?

Requiring a C++ compiler to build Emacs is a big practical
disadvantage.  Including C++ code in Emacs will be an obstacle for
people such as me to debug or write code.  That is independent of what
jobs the C++ code is used to do.

Apparently, C++ has been used in support for the Haiku system.  That's
unfortunate, but at least it is only an issue for users concerned with
the Haiku system.  Most of us have no need to debug or read that code
since we never run it.

Using it in code that runs on the GNU system would make the problem
much more serious.  No, no, no!

However, you also wrote this:

  > The GUI parts requiring C++ can be neatly separated from the rest of the
  > C code through such glue.

That might affect the issue.  Can you explain this more?

You recommended we look at haiku_support.cc to see this technique.
But that file is 4000 lines long.  I can't look through so much
hoping to recognize the part you refer to.

Could you please describe concretely the technique you refer to, or
show precisely what code in that file illustrates it?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> That might affect the issue.  Can you explain this more?
>
> You recommended we look at haiku_support.cc to see this technique.
> But that file is 4000 lines long.  I can't look through so much
> hoping to recognize the part you refer to.
>
> Could you please describe concretely the technique you refer to, or
> show precisely what code in that file illustrates it?

Basically, the file provides a C wrapper around C++ functions.  All of
those C wrapper functions are declared in haiku_support.c, and have C
linkage, meaning that they can be called from C code.

Instances of C++ objects are passed to C as pointers to void, and C code
interacts with the C++ objects through only the wrapper functions.  It
doesn't include lisp.h, dispextern.h, keyboard.h, or any other header
that is part of the Emacs C code, and only calls functions declared
there through function pointers explictly provided by the C code in
haikuterm.c (and other pieces of code in C.)

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Basically, the file provides a C wrapper around C++ functions.

I can understand that in a general conceptual sense,
but would you please show me how ONE function is handled,
in the various files, and explain the crucial things in it?
Including the C++ constructs that are used?  I don't know C++.

  > Basically, the file provides a C wrapper around C++ functions.

Are the C++ functions all external to Emacs?
Exported by the operating system?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> I can understand that in a general conceptual sense,
> but would you please show me how ONE function is handled,
> in the various files, and explain the crucial things in it?
> Including the C++ constructs that are used?  I don't know C++.

Take the example of the extern "C" function BAlert_new:

/* Create a BAlert with TEXT.  */
void *
BAlert_new (const char *text, enum haiku_alert_type type)
{
  return new BAlert (NULL, text, NULL, NULL, NULL, B_WIDTH_AS_USUAL,
		     (enum alert_type) type);
}

it's a wrapper around the C++ constructor for the alert dialog class
"BAlert", and returns the result of the constructor (the new instance of
the C++ class) as a pointer to void.  Conceptually, it would be the same
as:

  pointer = malloc (sizeof BAlert);
  constructor_of_balert (pointer);

  return pointer;

Then, this extern "C" function takes the resulting void pointer and
deletes it, by calling the C++ destructor:

void
BAlert_delete (void *alert)
{
  delete (BAlert *) alert;
}

> Are the C++ functions all external to Emacs?
> Exported by the operating system?

Yes.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Mon, 22 Aug 2022 23:44:24 -0400
> 
>   > What's wrong with C++ in GUI code?
> 
> Requiring a C++ compiler to build Emacs is a big practical
> disadvantage.  Including C++ code in Emacs will be an obstacle for
> people such as me to debug or write code.  That is independent of what
> jobs the C++ code is used to do.

I think you have in mind use of all the advanced features of C++,
which makes debugging harder.  But that is not the intent, and is not
really needed for this purpose.

> Using it in code that runs on the GNU system would make the problem
> much more serious.  No, no, no!

Like I said, we already have that in two flagship projects: GCC and
GDB.  And they actually do use almost the full spectrum of C++
features, all over the place.

By contrast, if we ever go this way (and due to the license issue it
doesn't currently look like we will), the C++ code will be limited to
the back-end parts of the display code, basically the
equivalents/siblings of xterm.c and xfns.c.  That is an entirely
different scale.

Re: Abysmal state of GTK build

[Lynn Winebarger]

On Mon, Aug 22, 2022 at 11:47 PM Richard Stallman <rms@gnu.org> wrote:
> Requiring a C++ compiler to build Emacs is a big practical
> disadvantage.  Including C++ code in Emacs will be an obstacle for
> people such as me to debug or write code.  That is independent of what
> jobs the C++ code is used to do.

Could you elaborate on why this is an issue when C++ infrastructure
(including GNU C++ infrastructure) is so widely available?  There is a
lot of infrastructure code written in C++, evidently including GUI
frameworks, so it's not like this decision is cost free.

TIA,
Lynn

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Requiring a C++ compiler to build Emacs is a big practical
  > > disadvantage.  Including C++ code in Emacs will be an obstacle for
  > > people such as me to debug or write code.

  > Could you elaborate on why this is an issue

C++ is a complex language.  I don't want Emacs to require developers
to know C++.

                                                when C++ infrastructure
  > (including GNU C++ infrastructure) is so widely available?

I'm sure there will be some users for which getting that running is a
hassle.  It may be a minority, in which case this would be a secondary
problem.  Maybe this by itself would not be enough of a reason not to
use C++.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Robert Pluim]

>>>>> On Tue, 23 Aug 2022 23:52:58 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> > Requiring a C++ compiler to build Emacs is a big practical
    >> > disadvantage.  Including C++ code in Emacs will be an obstacle for
    >> > people such as me to debug or write code.

    >> Could you elaborate on why this is an issue

    Richard> C++ is a complex language.  I don't want Emacs to require developers
    Richard> to know C++.

Meh. C-with-macros as used all over Emacs is complex as well, and also
requires learning. Iʼm neither a C++ fanboy nor an expert in "modern"
C++, but if it can be used to reduce complexity Iʼm all for it. GDB
seems to have had some success with it.

    Richard>                                                 when C++ infrastructure
    >> (including GNU C++ infrastructure) is so widely available?

    Richard> I'm sure there will be some users for which getting that running is a
    Richard> hassle.  It may be a minority, in which case this would be a secondary
    Richard> problem.  Maybe this by itself would not be enough of a reason not to
    Richard> use C++.

I canʼt think of a major platform for Emacs which doesnʼt have a C++
compiler (MS-DOS maybe?)

Robert
-- 

Re: Abysmal state of GTK build

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> Meh. C-with-macros as used all over Emacs is complex as well, and also
> requires learning. Iʼm neither a C++ fanboy nor an expert in "modern"
> C++, but if it can be used to reduce complexity Iʼm all for it. GDB
> seems to have had some success with it.

FWIW, I object to requiring C++ for the build, simply because it's not a
language I know very well.  But there is nothing wrong with implementing
a GUI backend in C++: we already require non-C languages for both the
Nextstep and Haiku window systems.

> I canʼt think of a major platform for Emacs which doesnʼt have a C++
> compiler (MS-DOS maybe?)

DJGPP supports C++, but I have no idea if its C++ library is
unexec-ready (the MS-DOS build only supports unexec.)

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Richard Stallman <rms@gnu.org>,  Lynn Winebarger <owinebar@gmail.com>,
>  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Wed, 24 Aug 2022 18:43:20 +0800
> 
> > I canʼt think of a major platform for Emacs which doesnʼt have a C++
> > compiler (MS-DOS maybe?)
> 
> DJGPP supports C++, but I have no idea if its C++ library is
> unexec-ready (the MS-DOS build only supports unexec.)

That C++ library is GNU libstdc++, nothing less, nothing more.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lynn Winebarger <owinebar@gmail.com>,  luangruo@yahoo.com,
>  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Wed, 24 Aug 2022 10:57:36 +0200
> 
> I canʼt think of a major platform for Emacs which doesnʼt have a C++
> compiler (MS-DOS maybe?)

What is called "MS-DOS" in this context uses GCC, so certainly it has
a C++ compiler, which is part of the GCC suite.

Re: Abysmal state of GTK build

[Gerd Möllmann]

 > Meh. C-with-macros as used all over Emacs is complex as well, and also
 > requires learning.

+1

 > Iʼm neither a C++ fanboy nor an expert in "modern"
 > C++, but if it can be used to reduce complexity Iʼm all for it. GDB
 > seems to have had some success with it.

I'm also far fromt a fanboy.  I think I see this from a practical 
standpoint and I agree fully with GCC and GDB folks.  To quote a slide
from Ian Lance Taylor (Write gcc in C++, 2008)

- C++ is a standardized, well known, popular language.
- C++ is nearly a superset of C90 used in gcc.
- The C subset of C++ is just as efficient as C.
- C++ supports cleaner code in several significant cases.
- C++ makes it easier to write cleaner interfaces by making it harder to 
break interface boundaries.
- C++ never requires uglier code.
- C++ is not a panacea but it is an improvement.

Take a look at xdisp.c, and imagine what that will look like in another 
20 years if nothing happens.

Re: Abysmal state of GTK build

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Take a look at xdisp.c, and imagine what that will look like in
> another 20 years if nothing happens.

I don't quite believe that C++ will make it look any better, without
someone doing the work to clean it up.  Which might as well be done in
C.

Re: Abysmal state of GTK build

[Gerd Möllmann]

On 22-08-25 8:52 , Po Lu wrote:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
>> Take a look at xdisp.c, and imagine what that will look like in
>> another 20 years if nothing happens.
> 
> I don't quite believe that C++ will make it look any better, without
> someone doing the work to clean it up.  Which might as well be done in
> C.

Obviously I disagree, and I might add that I know both C++ and xdisp.c 
quite well.  Xdisp.c not as well as I once did, but anyway.

Re: xdisp.c in C++ (Was: Abysmal state of GTK build)

[Eli Zaretskii]

> Date: Thu, 25 Aug 2022 08:57:34 +0200
> Cc: rpluim@gmail.com, emacs-devel@gnu.org, ofv@wanadoo.es,
>  owinebar@gmail.com, rms@gnu.org
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
> On 22-08-25 8:52 , Po Lu wrote:
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> > 
> >> Take a look at xdisp.c, and imagine what that will look like in
> >> another 20 years if nothing happens.
> > 
> > I don't quite believe that C++ will make it look any better, without
> > someone doing the work to clean it up.  Which might as well be done in
> > C.
> 
> Obviously I disagree, and I might add that I know both C++ and xdisp.c 
> quite well.  Xdisp.c not as well as I once did, but anyway.

Feel free to describe how rewriting xdisp.c in C++ could make it
significantly easier to understand and maintain.  We might as well
consider doing something still in C, if any of the ideas sound
attractive.

It is quite obvious that the various methods in
get_next_display_element and set_iterator_to_next could use
polymorphism, and the iterator object itself could be rewritten in
C++.  Likewise the handle_stop handlers.  But will this really make
the code simpler and easier to understand?

And what else in xdisp.c will benefit from rewriting it in C++?

(This is obviously a very academic discussion at this point, so I'll
understand if you don't want to invest any real time in it.  I asked
those questions on the chance that you already have most of the
answers figured out and ready.)

Re: xdisp.c in C++ (Was: Abysmal state of GTK build)

[Gerd Möllmann]

On 22-08-25 10:28 , Eli Zaretskii wrote:
> Feel free to describe how rewriting xdisp.c in C++ could make it
> significantly easier to understand and maintain.  We might as well
> consider doing something still in C, if any of the ideas sound
> attractive.
> 
> It is quite obvious that the various methods in
> get_next_display_element and set_iterator_to_next could use
> polymorphism, and the iterator object itself could be rewritten in
> C++.  Likewise the handle_stop handlers.  But will this really make
> the code simpler and easier to understand?
> 
> And what else in xdisp.c will benefit from rewriting it in C++?
> 
> (This is obviously a very academic discussion at this point, so I'll
> understand if you don't want to invest any real time in it.  I asked
> those questions on the chance that you already have most of the
> answers figured out and ready.)

Yup, it's academic.  If I had to bet, I'd say nothing will change :-).
And I don't carry a design in my head.  And I don't know if I would work 
on it anyway because Emacs doesn't play that big a role in my life 
nowadays, and I might as well be dead or hand shaking thin air until 
changing something would pay off.

What I wanted to convey is that I perceive a problem, that I think it 
should be addressed for the long run, and that following the path of GCC 
and GDB would be good.

One can say the problem doesn't exist, or it's not that grave.  Or one 
can say we don't need C++ to solve the problem, which is what Po Lu 
thinks, I believe.  Or no-one will work on this.  And so on, that's all 
fine, I don't want to argue here ad infinitum.

 From my POV, the one thing that's certain is that making things 
impossible ensures they won't happen.

A definite decision would make me happy. If it's the right one, of 
course :-).

That should be it from my side.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Speaking of Haiku, I see that many of the files have underscore in
their names.  Our normal convention in GNU is to use dashes in file
names, not underscores.  Could you please regularize these names?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Speaking of Haiku, I see that many of the files have underscore in
> their names.  Our normal convention in GNU is to use dashes in file
> names, not underscores.  Could you please regularize these names?

Sure.  I wasn't aware that convention also applies to C++ files.  I
think I can also come up with shorter names for those files as well.

Re: Abysmal state of GTK build

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Sure.  I wasn't aware that convention also applies to C++ files.  I
> think I can also come up with shorter names for those files as well

Do we really need those file names to be shorter?

Re: Abysmal state of GTK build

[Po Lu]

Stefan Kangas <stefan@marxist.se> writes:

> Do we really need those file names to be shorter?

Yes, at present the over-long file names are pretty ugly.

Re: Abysmal state of GTK build

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

>> Do we really need those file names to be shorter?
>
> Yes, at present the over-long file names are pretty ugly.

FWIW, I appreciate that you can tell what they are, even at a glance.

Compare "haiku-font-support.cc" to something like "cm.c" or "unexcw.c".

Re: Abysmal state of GTK build

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> Do we really need those file names to be shorter?
>>
>> Yes, at present the over-long file names are pretty ugly.
>
> FWIW, I appreciate that you can tell what they are, even at a glance.
>
> Compare "haiku-font-support.cc" to something like "cm.c" or "unexcw.c".

Sounds reasonable.  I won't shorten the file names then, thanks.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Speaking of Haiku, I see that many of the files have underscore in
  > > their names.  Our normal convention in GNU is to use dashes in file
  > > names, not underscores.  Could you please regularize these names?

  > Sure.  I wasn't aware that convention also applies to C++ files.  I
  > think I can also come up with shorter names for those files as well.

Switching to dashes would be an increase in consistency.  Thanks.

However, I'm not sure there is any drawback nowadays to file names of
that lengfth.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> That would also get us another native Wayland backend, and probably one
> that would could more heartily recommend to people.

Qt Wayland still doesn't work very well the last time I checked.

Re: Abysmal state of GTK build

[Visuwesh]

[ஞாயிறு ஆகஸ்ட் 21, 2022] Robert Pluim wrote:

>
>>>>>> On Sun, 21 Aug 2022 19:39:34 +0800, Po Lu <luangruo@yahoo.com> said:
>
>     Po Lu> Eli Zaretskii <eliz@gnu.org> writes:
>     >> Why not Lucid?
>
>     Po Lu> I forgot to include that, sorry.  I meant it along with the Motif build,
>     Po Lu> since both work equally well.  Several months ago only the Motif build
>     Po Lu> was usable under XInput 2, but all of those bugs were eliminated between
>     Po Lu> then and now.
>
> There was a time when I was young and naïve, and thought that GTK was
> going to be the answer to Emacsʼ toolkit issues. That has turned out
> to be somewhat untrue [1], so perhaps we should default to Lucid (itʼs
> still pretty ugly, but I donʼt use menus or scrollbars so that doesnʼt
> affect me personally).

One potential with the Lucid backend is that it does not support the
XEmbed protocol IIRC.

Re: Abysmal state of GTK build

[Po Lu]

Visuwesh <visuweshm@gmail.com> writes:

> One potential with the Lucid backend is that it does not support the
> XEmbed protocol IIRC.

If someone tells me why it doesn't work, I'd be happy to fix that.

Re: Abysmal state of GTK build

[Visuwesh]

[திங்கள் ஆகஸ்ட் 22, 2022] Po Lu wrote:

>
> Visuwesh <visuweshm@gmail.com> writes:
>
>> One potential with the Lucid backend is that it does not support the
>> XEmbed protocol IIRC.
>
> If someone tells me why it doesn't work, I'd be happy to fix that.

Unfortunately, I only know that it does not work, not why.  I quickly
searched emacs-devel, bug-gnu-emacs and the Git history (+ the
Changelogs) for "xembed" in the subjects but they returned nothing
fruitful.

Re: Abysmal state of GTK build

[Po Lu]

Robert Pluim <rpluim@gmail.com> writes:

> There was a time when I was young and naïve, and thought that GTK was
> going to be the answer to Emacsʼ toolkit issues.

+1.

> That has turned out to be somewhat untrue [1], so perhaps we should
> default to Lucid (itʼs still pretty ugly, but I donʼt use menus or
> scrollbars so that doesnʼt affect me personally). If Someone™
> contributes a Qt port, that might do as well (there was a port of
> XEmacs to Qt several decades ago, so it definitely feasible).

I suggest anyone who wants to implement a port to Qt look at the Haiku
port.  I think both toolkits are designed similarly from a high-level
perspective, and both require C++ for the GUI code.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If Someone™ contributes a Qt port, that might
  > do as well (there was a port of XEmacs to Qt several decades ago, so
  > it definitely feasible).

Qt has a grave problem: its license.  It is released undeer GNU GPL
version 3 _only_.  That means that if someday we have a GPL version 4,
when we upgrade Emacs to GPL version 4-or-later, it will be
license-incompatible with GPL 3.

The Qt developers might change to GPL 3-or-4, but we can't assume they
will do so.

Use of C++ is another problem.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > If Someone™ contributes a Qt port, that might
>   > do as well (there was a port of XEmacs to Qt several decades ago, so
>   > it definitely feasible).
>
> Qt has a grave problem: its license.  It is released undeer GNU GPL
> version 3 _only_.  That means that if someday we have a GPL version 4,
> when we upgrade Emacs to GPL version 4-or-later, it will be
> license-incompatible with GPL 3.
>
> The Qt developers might change to GPL 3-or-4, but we can't assume they
> will do so.

We can keep the Qt port in isolation from the rest of Emacs, and then,
if we ever upgrade to GPL version 4-or-later, we can kick out the port
until Qt also upgrades their license.

>
> Use of C++ is another problem.

Yeah, writing C++ may seem to be pleasant, but it becomes horrible when
you get an compile error with a thousand lines backtrace of types and
templates.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Abysmal state of GTK build

[Po Lu]

Akib Azmain Turja <akib@disroot.org> writes:

> Yeah, writing C++ may seem to be pleasant, but it becomes horrible when
> you get an compile error with a thousand lines backtrace of types and
> templates.

I never saw that writing the Haiku port.  Besides, such errors are
history in modern versions of GCC.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> Users of the GTK 3 build experience many, many problems.  The most
> recent such problem is bug#56869, which is definitely a bug in GTK.

Yes, and we have to fix bug#56869 by working around the problem, as we
do with all OS/library-related issues.  Just because it's something else
that's "wrong" doesn't mean we can ignore the issue.

> Taking into account the very low quality of the GDK X11 backend, which
> is not seeing active maintenance, shouldn't the build default to some
> other toolkit such as Motif, or even better, no toolkit at all?
>
> Especially considering that a GTK developer (the tail) wants to remove
> support for X11 (the dog) in future releases of GTK:
>
>   https://gitlab.gnome.org/GNOME/gtk/-/issues/5004

Love the ending there:

"Since this issue found its way on Phoronix and reddit I'm going to
temporarily lock it, to ensure a modicum of decency and avoid lowering
the bar of the comments."

Anyway, I'm all in favour of defaulting to a no-toolkit build (across
all systems -- the astounding success of VS Code has show that having a
consistent look across systems is much more important than respecting
the look of the OS).

But we have to fix the no-toolkit look before we can contemplate that.

1) New toolbar icons:

  

[-- Attachment #2: Type: image/png, Size: 3469 bytes --]

[-- Attachment #3: Type: text/plain, Size: 204 bytes --]


We need somebody, preferably a designer, to put together a set of
consistent (and pretty) toolbar icons.

2) Background glitches:

I've got *background: black, and that makes "emacs -Q" look like this:


[-- Attachment #4: Type: image/png, Size: 9942 bytes --]

[-- Attachment #5: Type: image/png, Size: 782 bytes --]

[-- Attachment #6: Type: text/plain, Size: 43 bytes --]


That has to be fixed.

3) Menu bar font:


[-- Attachment #7: Type: image/png, Size: 2814 bytes --]

[-- Attachment #8: Type: text/plain, Size: 644 bytes --]


Must be proportional to not look like an artefact of the 80s.

4) HiDPI problems in the menus: The menus are unreadably small on a
HiDPI display.

5) The scroll bar has to be fixed to work as modern scroll bars to, not
emulate the actions of an 80s Xterm.  I.e., you have to be able to drag
the scrool widget, and click above and below it, and have the thing
happen that normal users expect.

Once those five things are in place, we should default to a no-toolkit
build, which will give us a lot more control of Emacs behaviour, and not
rely on odd tics in each toolkit, and in addition, allow
daemon/multi-display shutdown to work reliably.

Re: Abysmal state of GTK build

[Visuwesh]

[ஞாயிறு ஆகஸ்ட் 21, 2022] Lars Ingebrigtsen wrote:

> 5) The scroll bar has to be fixed to work as modern scroll bars to, not
> emulate the actions of an 80s Xterm.  I.e., you have to be able to drag
> the scrool widget, and click above and below it, and have the thing
> happen that normal users expect.

I find the "modern" scrollbar a waste of screen space precisely because
they do not behave like the 80s Xterm scrollbar.
[ Argument can be made to make down-mouse-1 and down-mouse-2 to continue
  scrolling and I think that's a good change but please do not make the
  current scrollbars as useless as the "modern" ones.  ]

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Anyway, I'm all in favour of defaulting to a no-toolkit build (across
> all systems

(But note that our decisions here will probably not matter one whit to
most of our users -- Ubuntu/Debian will almost certainly continue to
distribute Emacs with a gtk toolkit.)

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (But note that our decisions here will probably not matter one whit to
> most of our users -- Ubuntu/Debian will almost certainly continue to
> distribute Emacs with a gtk toolkit.)

Don't they listen to our choices?

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Don't they listen to our choices?

Nope.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Don't they listen to our choices?
>
> Nope.

Well, let me qualify that a bit: I think if we can make the default
non-Gtk toolkit version of Emacs pretty enough (and usable enough for a
reasonable user), and have compelling reasons to discourage the
Gtk-toolkit version (I think the _exit when a display shuts down, and
the XInput2 problems, might be compelling), then we might convince them.

But without the 1-5) I outlined, I don't think there's any chance
what-so-ever.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, let me qualify that a bit: I think if we can make the default
> non-Gtk toolkit version of Emacs pretty enough (and usable enough for a
> reasonable user), and have compelling reasons to discourage the
> Gtk-toolkit version (I think the _exit when a display shuts down, and
> the XInput2 problems, might be compelling), then we might convince them.

Prettyness is hardly useful when the software itself crashes.

Especially with the modern idea of "pretty", which is rounded corners,
low-contrast icons, animations and blur.  Aside from that, the GTK build
already has enough compelling problems for almost anyone to switch from
it, just look at this part of etc/PROBLEMS:

  *** Emacs built with GTK+ toolkit can unexpectedly widen frames

  This resizing takes place when a frame is not wide enough to accommodate
  its entire menu bar.  Typically, it occurs when switching buffers or
  changing a buffer's major mode and the new mode adds entries to the menu
  bar.  The frame is then widened by the window manager so that the menu
  bar is fully shown.  Subsequently switching to another buffer or
  changing the buffer's mode will not shrink the frame back to its
  previous width.  The height of the frame remains unaltered.  Apparently,
  the failure is also dependent on the chosen font.

  The resizing is usually accompanied by console output like

  Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

  It's not clear whether the GTK version used has any impact on the
  occurrence of the failure.  So far, the failure has been observed with
  GTK+ versions 3.4.2, 3.14.5 and 3.18.7.  However, another 3.4.2 build
  does not exhibit the bug.

  Some window managers (Xfce) apparently work around this failure by
  cropping the menu bar.  With other windows managers, it's possible to
  shrink the frame manually after the problem occurs, e.g. by dragging the
  frame's border with the mouse.  However, some window managers have been
  reported to refuse such attempts and snap back to the width needed to
  show the full menu bar (wmii) or at least cause the screen to flicker
  during such resizing attempts (i3, IceWM).

  See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15700,
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22000,
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22898 and
  https://lists.gnu.org/r/emacs-devel/2016-07/msg00154.html.

That bug is particularly nasty.  I tried my best to get rid of it, but
it still pops up once in a while, usually when the user switches to a
Dired buffer, which has a very long menu bar.  Despite the frame being
maximized on some window managers, which is probably very annoying.

I think the reason users use the GTK build despite those problems is
because it is the default, and they don't know any better.  Then,
because they assume that the developers of a major toolkit are better at
their job than us, blame for the resulting problems is assigned to
Emacs, which results in shouting on the bug tracker.

In the meantime, we have to endure the low-quality work of the GTK
developers, in whose world files cannot be saved after the window server
is shut down, and users and developers who turn off GTK mis-features are
"clowns", "the internet peanut gallery", and have their knobs yanked out
from underneath:

  https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829

> But without the 1-5) I outlined, I don't think there's any chance
> what-so-ever.

Were they fine with the Lucid build before the GTK build became the
default?

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

[Problems with Gtk snipped -- I agree that all of those things are bad.]

> I think the reason users use the GTK build despite those problems is
> because it is the default, and they don't know any better.

Most users don't choose the toolkits -- they use whatever the
distribution has configured.  And since most of those use a variation on
Gnome Shell, it's natural for the distributions to use the Gtk toolkit
for Emacs.

But, yes, most people who build Emacs themselves end up using the Gtk
toolkit for two reasons: It's the default, and the no-toolkit one is
ugly and unusable (both in actuality and as a UX preference for most
normal people).

>> But without the 1-5) I outlined, I don't think there's any chance
>> what-so-ever.
>
> Were they fine with the Lucid build before the GTK build became the
> default?

Did the distributions exist before Gtk?

I haven't tried the Lucid build in a while, and it fixes the menu
scaling (and font) issues.  Otherwise, it has all the same problems that
the no-toolkit version has.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Most users don't choose the toolkits -- they use whatever the
> distribution has configured.  And since most of those use a variation on
> Gnome Shell, it's natural for the distributions to use the Gtk toolkit
> for Emacs.

Can't we shout at them to do something else? I've seen the Debian Emacs
packager here somewhere.

> But, yes, most people who build Emacs themselves end up using the Gtk
> toolkit for two reasons: It's the default, and the no-toolkit one is
> ugly and unusable (both in actuality and as a UX preference for most
> normal people).

Unusable?

> Did the distributions exist before Gtk?

Yes.  Emacs gained support for GTK+ in the early 2000s, and enabled it by
default with 23.1.

> I haven't tried the Lucid build in a while, and it fixes the menu
> scaling (and font) issues.

I think menu font scaling works fine on the Lucid build.  Scaling the
menus themselves (i.e. the border around highlighted menu items) most
likely does not, and I don't have the necessary hardware to test any
implementation of that type of scaling.  (If I did, we wouldn't even be
having this discussion right now -- I've repeatedly wanted to really fix
HiDPI support over the past several months.)

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> But, yes, most people who build Emacs themselves end up using the Gtk
>> toolkit for two reasons: It's the default, and the no-toolkit one is
>> ugly and unusable (both in actuality and as a UX preference for most
>> normal people).
>
> Unusable?

Yes.  The menus as so tiny that they can't be used.

> I think menu font scaling works fine on the Lucid build.  Scaling the
> menus themselves (i.e. the border around highlighted menu items) most
> likely does not, and I don't have the necessary hardware to test any
> implementation of that type of scaling.

No, the menus themselves are scaled just fine using Lucid.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes.  The menus as so tiny that they can't be used.

You're using a HiDPI screen, which hasn't really caught on yet.  The
moment I can get at one, I will definitely fix that.

> No, the menus themselves are scaled just fine using Lucid.

Compare the thickness of the borders as displayed on your monitor with
the borders on a monitor of regular density.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> No, the menus themselves are scaled just fine using Lucid.
>
> Compare the thickness of the borders as displayed on your monitor with
> the borders on a monitor of regular density.

I wasn't really talking about the borders, but the text.

Re: Abysmal state of GTK build

[Dmitry Gutov]

On 21.08.2022 17:20, Po Lu wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>> Yes.  The menus as so tiny that they can't be used.
> 
> You're using a HiDPI screen, which hasn't really caught on yet.

It has. Just not 100%.

> The
> moment I can get at one, I will definitely fix that.

I think you can turn on 2x scaling even on a Full HD screen? Just use a 
smaller resolution, like 960x540.

If not, perhaps some of us could chip in for your hardware upgrade. It 
shouldn't take too many people: HiDPI monitors are pretty available 
these days.

Re: Abysmal state of GTK build

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I think you can turn on 2x scaling even on a Full HD screen? Just use
> a smaller resolution, like 960x540.

Testing with such a setup proved to be really annoying.

> If not, perhaps some of us could chip in for your hardware upgrade. It
> shouldn't take too many people: HiDPI monitors are pretty available
> these days.

No need, I think I will get one such monitor myself at some point.  My
current external monitor is on its last legs.

Re: Abysmal state of GTK build

[Stefan Monnier]

Po Lu [2022-08-21 22:16:04] wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> Most users don't choose the toolkits -- they use whatever the
>> distribution has configured.  And since most of those use a variation on
>> Gnome Shell, it's natural for the distributions to use the Gtk toolkit
>> for Emacs.
> Can't we shout at them to do something else? I've seen the Debian Emacs
> packager here somewhere.

Indeed, Rob does pay attention to what we say.  He also has to pay
attention to what other people say.  We all think we're right.


        Stefan "using Emacs with Lucid, mostly"

Re: Abysmal state of GTK build

[Rob Browning]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Po Lu [2022-08-21 22:16:04] wrote:
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>> Most users don't choose the toolkits -- they use whatever the
>>> distribution has configured.  And since most of those use a variation on
>>> Gnome Shell, it's natural for the distributions to use the Gtk toolkit
>>> for Emacs.
>> Can't we shout at them to do something else? I've seen the Debian Emacs
>> packager here somewhere.
>
> Indeed, Rob does pay attention to what we say.  He also has to pay
> attention to what other people say.  We all think we're right.
>
>
>         Stefan "using Emacs with Lucid, mostly"

...for some version of "pay attention".  I certainly care, but I'm also
often swamped[1], and yes there are competing concerns.

For what it's worth, I don't personally have any strong, principled
stand regarding what the default toolkit should be right now (via "apt
install emacs").  If I recall correctly, I think I may have switched it
to gtk years back when it looked like that was the upstream preference.

Personally, I haven't installed emacs-gtk much in years.  I switched to
emacs-lucid nearly exclusively a good while back because I hit the well
known X forwarding bugs back when that was important to me.  (I also
turn off menu/tool/scroll bars, so I don't see a lot of the
toolkit-specific bits.)

Also for what it's worth, I am definitely inclined to favor upstream
preferences (in general) when I know what they are, resources
permitting, etc.

[1] ...and while I should be subscribed to emacs-devel, I don't read it
    right now; noticed this thread because someone pinged me.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Abysmal state of GTK build

[Sean Whitton]

Hello,

On Sun 21 Aug 2022 at 02:27PM -05, Rob Browning wrote:

> For what it's worth, I don't personally have any strong, principled
> stand regarding what the default toolkit should be right now (via "apt
> install emacs").  If I recall correctly, I think I may have switched it
> to gtk years back when it looked like that was the upstream preference.
>
> Personally, I haven't installed emacs-gtk much in years.  I switched to
> emacs-lucid nearly exclusively a good while back because I hit the well
> known X forwarding bugs back when that was important to me.  (I also
> turn off menu/tool/scroll bars, so I don't see a lot of the
> toolkit-specific bits.)

So, in your view it would be fine if we didn't use -gtk by default even
though GNOME is Debian's default desktop?

-- 
Sean Whitton

Re: Abysmal state of GTK build

[Rob Browning]

Sean Whitton <spwhitton@spwhitton.name> writes:

> So, in your view it would be fine if we didn't use -gtk by default even
> though GNOME is Debian's default desktop?

I don't think I have any categorical opinion on that front either in
general, or at the moment.  And since I don't use gnome, emacs-gtk, or
emacs tool/menu/scroll bars right now (and haven't for a long while),
I'd need more information.

One broad question might be "what is 'apt install emacs' for"?[1]
i.e. is it intended to provide the "best/preferred typical emacs", and
people should expect that it might produce substantially disruptive
changes over time (presumably only on major debian release boundaries),
i.e. lucid -> gtk -> something-new, or is it intended to provide the
emacs that goes with the default desktop (also potentially disruptive
across releases), or...

[1] Note to all that the "emacs" package is currently an empty
    metapackage that actually depends on "emacs-gtk | emacs-lucid |
    emacs-nox", so that any flavor will satisfy an "emacs" dependency,
    but the flavor listed first in the metapackage's dependencies is the
    one you get if you just try to install it directly.  I believe I
    chose that ordering years ago, based on what appeared to be the
    upstrem preferences at the time.

Ignoring the disruptive transition for a moment, I also wonder how much
it'd actually matter if emacs (eventually) preferred something other
than emacs-gtk.  Then people using gnome would "just" need to know to
install emacs-gtk or emacs-gnome instead of emacs.  (Any gnome-related
package that wants an emacs, could still depend on the concrete flavor
if appropriate.)

That said, given the potential disruption.  I might well be inclined to
set a moderately high bar for changes.  I also suspect a minor avalanche
of bugs will be filed if/when we do change the default to something
substantially different -- given varying opinions.

What's in a name?

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Abysmal state of GTK build

[Visuwesh]

[ஞாயிறு ஆகஸ்ட் 21, 2022] Sean Whitton wrote:

>> For what it's worth, I don't personally have any strong, principled
>> stand regarding what the default toolkit should be right now (via "apt
>> install emacs").  If I recall correctly, I think I may have switched it
>> to gtk years back when it looked like that was the upstream preference.
>>
>> Personally, I haven't installed emacs-gtk much in years.  I switched to
>> emacs-lucid nearly exclusively a good while back because I hit the well
>> known X forwarding bugs back when that was important to me.  (I also
>> turn off menu/tool/scroll bars, so I don't see a lot of the
>> toolkit-specific bits.)
>
> So, in your view it would be fine if we didn't use -gtk by default even
> though GNOME is Debian's default desktop?

Does the toolkit of Emacs matter?  The only annoyance I faced when using
Okular in a primarily Gtk system (all thanks to Chrome) was the file
picker but I'd argue that one does not use the toolkit's file picker in
Emacs often.  Heck, I went the other way and replace as much of the file
picker with dired+dragon(1) for _opening_ files (I'm still stuck with
the file picker for saving files).
[ But I say this as someone who does not mind the non-uniform look of
  programs as long as they work like they are supposed to.  Even VSCode
  does not look like a typical Gtk program AFAIU (and thank goodness it
  doesn't since the GNOME's current UI design is PITA to work with
  anyway).  ]

Re: Abysmal state of GTK build

[Po Lu]

Visuwesh <visuweshm@gmail.com> writes:

> Does the toolkit of Emacs matter?  The only annoyance I faced when using
> Okular in a primarily Gtk system (all thanks to Chrome) was the file
> picker but I'd argue that one does not use the toolkit's file picker in
> Emacs often.  Heck, I went the other way and replace as much of the file
> picker with dired+dragon(1) for _opening_ files (I'm still stuck with
> the file picker for saving files).

Unrelated, but tools like dragon are obsolete in Emacs 29.  See
dired-mouse-drag-files.

Re: Abysmal state of GTK build

[Sean Whitton]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

Hello,

On Sun 21 Aug 2022 at 10:16PM +08, Po Lu wrote:

>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Most users don't choose the toolkits -- they use whatever the
>> distribution has configured.  And since most of those use a variation on
>> Gnome Shell, it's natural for the distributions to use the Gtk toolkit
>> for Emacs.
>
> Can't we shout at them to do something else? I've seen the Debian Emacs
> packager here somewhere.

I'm one of the leads for the Debian Emacsen team, though with our
present internal organisation Rob Browning is the person who decides
what gets built, and what you get if you type 'apt-get install emacs'.

Lars is right: so long as GNOME Shell is Debian's default desktop
environment, it's unlikely that we'd change the default away from GTK,
and I don't believe there is any appetite among the desktop and
installer maintainers to switch away from GNOME Shell as the default.

The only other toolkit build we provide is Lucid.  If Emacs upstream
explicitly recommended a no toolkit build, we'd probably add that as
another option.

-- 
Sean Whitton

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 869 bytes --]

Re: Abysmal state of GTK build

[Lynn Winebarger]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Sun, Aug 21, 2022, 10:12 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> But, yes, most people who build Emacs themselves end up using the Gtk
> toolkit for two reasons: It's the default, and the no-toolkit one is
> ugly and unusable (both in actuality and as a UX preference for most
> normal people).
>

As I only recently took up building emacs for myself again, I can tell you
when I saw the choices for toolkit configuration, my reaction was (a) how
is no toolkit a viable option, and (b) who is using a window manager based
on the Motif or Lucid toolkits these days?
If there was a Qt option, I'd probably have taken it.  When I've used a
remote window manager on a local X server (versus a VNC based remote
display), GNOME just generated so much more X protocol traffic than KDE/Qt
that I'm wary of using it.  I don't know how much of that traffic is from
GTK, hence my bias toward Qt if it were already an option.

Lynn

[-- Attachment #2: Type: text/html, Size: 1537 bytes --]

Re: Abysmal state of GTK build

[Jean Louis]

* Lynn Winebarger <owinebar@gmail.com> [2022-08-21 18:29]:
> (b) who is using a window manager based on the Motif or Lucid
> toolkits these days?

I am using IceWM all the time. It is because it is fastest one. And I
use Lucid toolkit for Emacs because it appears more stable, more neat
to me. It is personal preference. I don't think that toolkit for Emacs
is related to Window manager's toolkit, it may be related only by
personal subjective preferences.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Abysmal state of GTK build

[Po Lu]

Lynn Winebarger <owinebar@gmail.com> writes:

> As I only recently took up building emacs for myself again, I can tell
> you when I saw the choices for toolkit configuration, my reaction was
> (a) how is no toolkit a viable option, and (b) who is using a window
> manager based on the Motif or Lucid toolkits these days?

For Motif, CDE (dtwm) and mwm users.  As for Lucid, no one, because the
Lucid tookit is internal to Emacs.

But to be fair, GNOME's window manager isn't based on GTK either, and
uses its own "Shell Toolkit".

Re: Abysmal state of GTK build

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
>> As I only recently took up building emacs for myself again, I can tell
>> you when I saw the choices for toolkit configuration, my reaction was
>> (a) how is no toolkit a viable option, and (b) who is using a window
>> manager based on the Motif or Lucid toolkits these days?
>
> For Motif, CDE (dtwm) and mwm users.  As for Lucid, no one, because the
> Lucid tookit is internal to Emacs.
>
> But to be fair, GNOME's window manager isn't based on GTK either, and
> uses its own "Shell Toolkit".


Like others in this thread, I don't use the menu-bar, toolbar,
scroll-bars etc, so toolkit seems somewhat irrelevant (I have to do an
M-x version to see which one I'm using!). I build using lucid as that
seemed like a better choice than gtk and I use xfce rather than gnome as
my desktop environment (and sometimes stumpwm).

I think one of the defining features of the GNU Linux desktop is the
wide variety and available choices wrt desktop environments. It really
doesn't matter what toolkit your window manager users except with
respect to the number of toolkits and libraries you have to install on
your system. 

I suspect a part of the decision regarding which toolkit to build emacs
with for various distros probably relates to minimising the number of
toolkits to install. As Gnome seems to be the current 'default', gtk is
already installed, so will likely be a preferred choice unless some
other compelling reason is given.

With Fedora now shipping with Wayland as default and the recent
announcement regarding nvidia driver licensing and support for nvidia
under wayland, I suspectg we will see a significant growth in
distributions defaulting to wayland and wanting to reduce/remove
dependency on X. 

One factor which will likely come into play if we changed the default
toolkit is theming. I've noticed that in both the most recent releases
of Ubuntu and Fedora, a lot of reviews and comments centred around
improved consistency in themes (especially consistency when switching
between light/dark themes). With a lucid build, I expect you will need
to setup X resources to match your theme. With the GTK build, it looks
like it inherits from whatever you set your default theme to (for menus
etc).

Personally, I tend to define my theme and just leave it. I do use a dark
theme and after many years, I have a good default Xresources, so not a
big issue for me (with the exception of some qt based apps). However,
for a generation brought up using Gnome, the whole xrdb stuff is likely
to be challenging/frustrating. I assume similar issues will exist for
the no toolket default. I don't think this is sufficient reason not to
change the default to (lets say) lucid - just mention it as I suspect it
will cause some disruption/frustration. There also seems to be a lot of
bad information about using/setting Xresources out there, which might
add to the confusion. 

Re: Abysmal state of GTK build

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> Like others in this thread, I don't use the menu-bar, toolbar,
> scroll-bars etc, so toolkit seems somewhat irrelevant (I have to do an
> M-x version to see which one I'm using!). I build using lucid as that
> seemed like a better choice than gtk and I use xfce rather than gnome as
> my desktop environment (and sometimes stumpwm).

[...]

> I suspect a part of the decision regarding which toolkit to build emacs
> with for various distros probably relates to minimising the number of
> toolkits to install. As Gnome seems to be the current 'default', gtk is
> already installed, so will likely be a preferred choice unless some
> other compelling reason is given.

The problem here is not a stylistic issue.  I want to disable the GTK
build by default because it leads to serious problems for users, up to
and including crashes.

> With Fedora now shipping with Wayland as default and the recent
> announcement regarding nvidia driver licensing and support for nvidia
> under wayland, I suspectg we will see a significant growth in
> distributions defaulting to wayland and wanting to reduce/remove
> dependency on X. 

The regular GTK build of Emacs will not run on GNOME Wayland either.
People who want to use Wayland should use the different PGTK build instead.

> One factor which will likely come into play if we changed the default
> toolkit is theming. I've noticed that in both the most recent releases
> of Ubuntu and Fedora, a lot of reviews and comments centred around
> improved consistency in themes (especially consistency when switching
> between light/dark themes). With a lucid build, I expect you will need
> to setup X resources to match your theme. With the GTK build, it looks
> like it inherits from whatever you set your default theme to (for menus
> etc).

Emacs's own interface doesn't respect any toolkit theme.

> Personally, I tend to define my theme and just leave it. I do use a dark
> theme and after many years, I have a good default Xresources, so not a
> big issue for me (with the exception of some qt based apps). However,
> for a generation brought up using Gnome, the whole xrdb stuff is likely
> to be challenging/frustrating. I assume similar issues will exist for
> the no toolket default.

The no toolkit build can be customized entirely with Lisp.

> I don't think this is sufficient reason not to change the default to
> (lets say) lucid - just mention it as I suspect it will cause some
> disruption/frustration. There also seems to be a lot of bad
> information about using/setting Xresources out there, which might add
> to the confusion.

Are you sure what you understand "this" is?  I'm going to say this
again: defaulting to the GTK build because it "looks better" or is "more
consistent" is quite simply trading crashes for looks.

Re: Abysmal state of GTK build

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Like others in this thread, I don't use the menu-bar, toolbar,
>> scroll-bars etc, so toolkit seems somewhat irrelevant (I have to do an
>> M-x version to see which one I'm using!). I build using lucid as that
>> seemed like a better choice than gtk and I use xfce rather than gnome as
>> my desktop environment (and sometimes stumpwm).
>
> [...]
>
>> I suspect a part of the decision regarding which toolkit to build emacs
>> with for various distros probably relates to minimising the number of
>> toolkits to install. As Gnome seems to be the current 'default', gtk is
>> already installed, so will likely be a preferred choice unless some
>> other compelling reason is given.
>
> The problem here is not a stylistic issue.  I want to disable the GTK
> build by default because it leads to serious problems for users, up to
> and including crashes.

You missed my point. I'm not saying the change is because of a stylistic
issue - I'm saying the change is likely to create a stylistic
issue. This will in turn cause more resistance to the change and
possibly increase motivation to do whatever is necessary to re-enable
gtk build. 

>
>> With Fedora now shipping with Wayland as default and the recent
>> announcement regarding nvidia driver licensing and support for nvidia
>> under wayland, I suspectg we will see a significant growth in
>> distributions defaulting to wayland and wanting to reduce/remove
>> dependency on X. 
>
> The regular GTK build of Emacs will not run on GNOME Wayland either.
> People who want to use Wayland should use the different PGTK build instead.
>

Yes, I know that and that is a problem for distributions where they want
to minimise the distro size and number of packages which need to be
maintained. As it stands now, most distributions include 3 packages -
emacs-gtk, emacs-lucid and emacs-nox. As they move to support wayland,
they will either have to include emacs-pgtk or continue with the
wayland-x interface. The risk is, given they need GTK for both emacs-gtk
and emacs-pgtk, they will drop the emacs-lucid package rather than the
emacs-gtk package (unless we help educate them on why that would be a
bad choice). To educate effectively, it helps to understand their
situation and not just address the technical issues seen from a pure
emacs development position.

>> One factor which will likely come into play if we changed the default
>> toolkit is theming. I've noticed that in both the most recent releases
>> of Ubuntu and Fedora, a lot of reviews and comments centred around
>> improved consistency in themes (especially consistency when switching
>> between light/dark themes). With a lucid build, I expect you will need
>> to setup X resources to match your theme. With the GTK build, it looks
>> like it inherits from whatever you set your default theme to (for menus
>> etc).
>
> Emacs's own interface doesn't respect any toolkit theme.

OK, so how does my Emacs default theme change between dark and light
theme when I change the theme of my desktop environment? This never use
to work and I assumed it was because emacs didn't respect the DE
theme. I use to manage it via X resources. However, I noticed on recent
installs under both Ubuntu and Fedora that changing between light and
dark themes also resulted in changes to (for example) the menus and
menu-bar from a light background with dark text to a dark background
with light text. My assumption was that this was due to the GTK theme
being respected?
>
>> Personally, I tend to define my theme and just leave it. I do use a dark
>> theme and after many years, I have a good default Xresources, so not a
>> big issue for me (with the exception of some qt based apps). However,
>> for a generation brought up using Gnome, the whole xrdb stuff is likely
>> to be challenging/frustrating. I assume similar issues will exist for
>> the no toolket default.
>
> The no toolkit build can be customized entirely with Lisp.
>

Which is fine for those who know lisp. However, this isn't what people
expect these days. THis was my point - lots of the comments and reviews
for recent distributions of Ubuntu and Fedora have referenced greatly
improved theme/style consistencies. From my own limited experience, this
appears to extend to Emacs as well (to a limited extent, not the whole
UI, just menus, popup dialogue boxes etc.

>> I don't think this is sufficient reason not to change the default to
>> (lets say) lucid - just mention it as I suspect it will cause some
>> disruption/frustration. There also seems to be a lot of bad
>> information about using/setting Xresources out there, which might add
>> to the confusion.
>
> Are you sure what you understand "this" is?  I'm going to say this
> again: defaulting to the GTK build because it "looks better" or is "more
> consistent" is quite simply trading crashes for looks.

Ignoring the level of motivation visual appeal/style has to peoples
decisions is likely to be somewhat naive. There are plenty of examples
of superior technology/solutions losing to inferior ones because of
non-technical reasons.

I also wonder about how frequent these crashes and technical issues
are. I switched over from gtk to lucid a little while ago. However,
prior to switching, I experienced absolutely no issues and I cannot
recall the last time Emacs crashed for me. I'm running latest emacs
devel (29.0.50) on Fedora 36 (previously on Ubutnu 22.04). I'm a heavy
Emacs users, running it every day all day and using it for nearly
everything. I switched to lucid because the technical arguments made
sense to me. However, I did not experience any of the technical issues
you reference. If my experience is more common, then your purely
technical argument is going to have difficulty gaining traction.

Re: Abysmal state of GTK build

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> You missed my point. I'm not saying the change is because of a stylistic
> issue - I'm saying the change is likely to create a stylistic
> issue. This will in turn cause more resistance to the change and
> possibly increase motivation to do whatever is necessary to re-enable
> gtk build. 

Reenabling the GTK build will be as easy as specifying
"--with-x-toolkit=gtk" at configure-time.  It's not being deleted.

> Yes, I know that and that is a problem for distributions where they want
> to minimise the distro size and number of packages which need to be
> maintained. As it stands now, most distributions include 3 packages -
> emacs-gtk, emacs-lucid and emacs-nox. As they move to support wayland,
> they will either have to include emacs-pgtk or continue with the
> wayland-x interface. The risk is, given they need GTK for both emacs-gtk
> and emacs-pgtk, they will drop the emacs-lucid package rather than the
> emacs-gtk package (unless we help educate them on why that would be a
> bad choice). To educate effectively, it helps to understand their
> situation and not just address the technical issues seen from a pure
> emacs development position.

They don't need anything extra for emacs-notoolkit.

> OK, so how does my Emacs default theme change between dark and light
> theme when I change the theme of my desktop environment? This never use
> to work and I assumed it was because emacs didn't respect the DE
> theme. I use to manage it via X resources. However, I noticed on recent
> installs under both Ubuntu and Fedora that changing between light and
> dark themes also resulted in changes to (for example) the menus and
> menu-bar from a light background with dark text to a dark background
> with light text. My assumption was that this was due to the GTK theme
> being respected?

The menu bar is not part of Emacs's own interface.

> Which is fine for those who know lisp. However, this isn't what people
> expect these days. THis was my point - lots of the comments and reviews
> for recent distributions of Ubuntu and Fedora have referenced greatly
> improved theme/style consistencies. From my own limited experience, this
> appears to extend to Emacs as well (to a limited extent, not the whole
> UI, just menus, popup dialogue boxes etc.

You can use Customize too, if you want.

> Ignoring the level of motivation visual appeal/style has to peoples
> decisions is likely to be somewhat naive. There are plenty of examples
> of superior technology/solutions losing to inferior ones because of
> non-technical reasons.

That doesn't mean it's a good idea to base our decisions on those
non-technical reaspons.

> I also wonder about how frequent these crashes and technical issues
> are. I switched over from gtk to lucid a little while ago. However,
> prior to switching, I experienced absolutely no issues and I cannot
> recall the last time Emacs crashed for me. I'm running latest emacs
> devel (29.0.50) on Fedora 36 (previously on Ubutnu 22.04). I'm a heavy
> Emacs users, running it every day all day and using it for nearly
> everything. I switched to lucid because the technical arguments made
> sense to me. However, I did not experience any of the technical issues
> you reference. If my experience is more common, then your purely
> technical argument is going to have difficulty gaining traction.

I'm going to say that you're simply lucky.  Search for "GTK" on the bug
tracker, in etc/PROBLEMS, and on this list, and you will see what I mean
very quickly.

Re: Abysmal state of GTK build

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> You missed my point. I'm not saying the change is because of a stylistic
>> issue - I'm saying the change is likely to create a stylistic
>> issue. This will in turn cause more resistance to the change and
>> possibly increase motivation to do whatever is necessary to re-enable
>> gtk build. 
>
> Reenabling the GTK build will be as easy as specifying
> "--with-x-toolkit=gtk" at configure-time.  It's not being deleted.
>

and again I feel your missing the point. Failing to address the
stylistic questions runs the risk that most people will just re-enable
the GTK theme. When this occurs, what have you actually achieved other
than now being able to say "Oh well, you chose GTK, so now its your
problem".

What is really required is that the default is changed away from GTK and
the majority of users are comfortable/happy with that change. This means
somehow addressing concerns which people are likely to raise with a
change in default toolkit. Dismissing them as irrelevant just because
they represent some current trend/style you find distasteful is unlikely
to help promote your proposal and gain acceptance. 

>> Yes, I know that and that is a problem for distributions where they want
>> to minimise the distro size and number of packages which need to be
>> maintained. As it stands now, most distributions include 3 packages -
>> emacs-gtk, emacs-lucid and emacs-nox. As they move to support wayland,
>> they will either have to include emacs-pgtk or continue with the
>> wayland-x interface. The risk is, given they need GTK for both emacs-gtk
>> and emacs-pgtk, they will drop the emacs-lucid package rather than the
>> emacs-gtk package (unless we help educate them on why that would be a
>> bad choice). To educate effectively, it helps to understand their
>> situation and not just address the technical issues seen from a pure
>> emacs development position.
>
> They don't need anything extra for emacs-notoolkit.
>

but they lose the ability to easily adopt a consistent theme across
their desktop - something which for whatever reason appears to work now
and will not once you change to either no toolkit or lucid.

>> OK, so how does my Emacs default theme change between dark and light
>> theme when I change the theme of my desktop environment? This never use
>> to work and I assumed it was because emacs didn't respect the DE
>> theme. I use to manage it via X resources. However, I noticed on recent
>> installs under both Ubuntu and Fedora that changing between light and
>> dark themes also resulted in changes to (for example) the menus and
>> menu-bar from a light background with dark text to a dark background
>> with light text. My assumption was that this was due to the GTK theme
>> being respected?
>
> The menu bar is not part of Emacs's own interface.
>

I don't really understand what you mean with this above statement. From
a user perspective, the menu-bar is obviously a part of the Emacs
interface and when I switch to lucid or no toolkit, it changes to a
light background and a dark foreground while everything else on my
desktop honours my selection of a dark background and a light
foreground. If I run the GTK build, the foreground/background is the
same as the other apps on my desktop i.e. dark background, light
foreground.

As outlined at the very beginning, this consistency in themes seems to
be something users want as can be seen in the prevalence of discussions
and reviews regarding recent GNU Linux distribution releases which focus
on this aspect. To minimise push-back and increase acceptance for a
toolkit default change, addressing such side issues will likely help
ensure a smoother transition. 

>> Which is fine for those who know lisp. However, this isn't what people
>> expect these days. THis was my point - lots of the comments and reviews
>> for recent distributions of Ubuntu and Fedora have referenced greatly
>> improved theme/style consistencies. From my own limited experience, this
>> appears to extend to Emacs as well (to a limited extent, not the whole
>> UI, just menus, popup dialogue boxes etc.
>
> You can use Customize too, if you want.
>

still missing the point. Users don't want to be required to go through
each individual application and manually adjust the theme to get a
consistent looking desktop. They have selected a desktop environment and
set a theme and want it applied consistently across the desktop. This
appears to be something they have with current GTK build and which you
don't get with lucid or no toolkit builds (at least on the Ubuntu and
Fedora DE I've used, YMMV with other combinations). I don't know how
easy it would be to address this issue - weather it would be possible to
add a basic 'interface' package or script or document some alternative
approaches to help people get the consistency which seems important with
minimal effort. 


>> Ignoring the level of motivation visual appeal/style has to peoples
>> decisions is likely to be somewhat naive. There are plenty of examples
>> of superior technology/solutions losing to inferior ones because of
>> non-technical reasons.
>
> That doesn't mean it's a good idea to base our decisions on those
> non-technical reaspons.
>

and that isn't what I said or suggested. At the risk of repeating myself
yet again, I'm not against the change in default toolkit. I'm merely
suggesting that if you want to minimise the push back to this change and
discourage people just manually selecting GTK, you need to also try and
address these separate, but related issues. Dismissing them as just
being irrelevant 'modern' trends will generate more heat and resistance
than necessary. 

>> I also wonder about how frequent these crashes and technical issues
>> are. I switched over from gtk to lucid a little while ago. However,
>> prior to switching, I experienced absolutely no issues and I cannot
>> recall the last time Emacs crashed for me. I'm running latest emacs
>> devel (29.0.50) on Fedora 36 (previously on Ubutnu 22.04). I'm a heavy
>> Emacs users, running it every day all day and using it for nearly
>> everything. I switched to lucid because the technical arguments made
>> sense to me. However, I did not experience any of the technical issues
>> you reference. If my experience is more common, then your purely
>> technical argument is going to have difficulty gaining traction.
>
> I'm going to say that you're simply lucky.  Search for "GTK" on the bug
> tracker, in etc/PROBLEMS, and on this list, and you will see what I mean
> very quickly.

However, that only gives a one sided view - all those people using the
GTK build who don't experience any problems don't report all is OK.

All I can report on is my personal experience. For me, I see no
instability with the GTK build. I also see little of benefit to me with
the switch to the new xinput2 and wonder why not just disable xinput2 in
just the GTK build so that if/when users select GTK as their preferred
toolkit, it is at least stable. I think it is quite reasonable to tell
people that if they want the features, such as pixel level scrolling,
then they have to use either no tookit or lucid and that the xinput2
features are not available in GTK.

It seems misguided to just change the default from GTK to no toolkit or
lucid and leave the ability to select GTK knowing that will cause
instability due to the use of xinput2. Change the default AND disable
xinput2 when someone selects the GTK toolkit. 

Re: Abysmal state of GTK build

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> and again I feel your missing the point. Failing to address the
> stylistic questions runs the risk that most people will just re-enable
> the GTK theme. When this occurs, what have you actually achieved other
> than now being able to say "Oh well, you chose GTK, so now its your
> problem".

If they run into problems in GTK at that point, we can just shrug and
ask them to complain to the GTK developers.

> but they lose the ability to easily adopt a consistent theme across
> their desktop - something which for whatever reason appears to work now
> and will not once you change to either no toolkit or lucid.

I wouldn't call a stylesheet applied to only the menu bar and scroll bar
"consistent".  It is hard to keep a GTK stylesheet consistent anyway,
because their developers keep breaking the stylesheet format, and now
there are GTK 4 programs that do not allow applying custom styles at
all.

> I don't really understand what you mean with this above statement. From
> a user perspective, the menu-bar is obviously a part of the Emacs
> interface and when I switch to lucid or no toolkit, it changes to a
> light background and a dark foreground while everything else on my
> desktop honours my selection of a dark background and a light
> foreground. If I run the GTK build, the foreground/background is the
> same as the other apps on my desktop i.e. dark background, light
> foreground.

[...]

> As outlined at the very beginning, this consistency in themes seems to
> be something users want as can be seen in the prevalence of discussions
> and reviews regarding recent GNU Linux distribution releases which focus
> on this aspect. To minimise push-back and increase acceptance for a
> toolkit default change, addressing such side issues will likely help
> ensure a smoother transition. 

So, in other words, you're fine with the menu bar being consistent with
the system stylesheet (something the GTK developers say not to apply,
and have outright deleted from many GTK 4 programs), while a Gnus
summary buffer is not?

> still missing the point. Users don't want to be required to go through
> each individual application and manually adjust the theme to get a
> consistent looking desktop. They have selected a desktop environment and
> set a theme and want it applied consistently across the desktop. This
> appears to be something they have with current GTK build and which you
> don't get with lucid or no toolkit builds (at least on the Ubuntu and
> Fedora DE I've used, YMMV with other combinations). I don't know how
> easy it would be to address this issue - weather it would be possible to
> add a basic 'interface' package or script or document some alternative
> approaches to help people get the consistency which seems important with
> minimal effort. 

Again, see what I said above.

> and that isn't what I said or suggested. At the risk of repeating myself
> yet again, I'm not against the change in default toolkit. I'm merely
> suggesting that if you want to minimise the push back to this change and
> discourage people just manually selecting GTK, you need to also try and
> address these separate, but related issues. Dismissing them as just
> being irrelevant 'modern' trends will generate more heat and resistance
> than necessary. 

I don't want to discourage people from manually selecting GTK.

> All I can report on is my personal experience. For me, I see no
> instability with the GTK build. I also see little of benefit to me with
> the switch to the new xinput2 and wonder why not just disable xinput2 in
> just the GTK build so that if/when users select GTK as their preferred
> toolkit, it is at least stable. I think it is quite reasonable to tell
> people that if they want the features, such as pixel level scrolling,
> then they have to use either no tookit or lucid and that the xinput2
> features are not available in GTK.

Because the core input subsystem is obsolete, like Xinerama,
multi-buffering, the original input extension, core fonts, and RandR
before 1.2.  It will not even work with new input devices in the future,
or under multi-pointer X environments, and the support in GTK itself
will be removed by GTK developers at some point.  Do this:

  xinput create-master test 0 1
  xinput reattach <another pointer device> <id of test master pointer>

and try to click on a frame from programs not using the input extension.
It will not work.

Consistent theme across the desktop [Re: Abysmal state of GTK build]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

On Tue, Aug 23, 2022 at 09:19:26AM +1000, Tim Cross wrote:

[...]

> but they lose the ability to easily adopt a consistent theme across
> their desktop - something which for whatever reason appears to work now
> and will not once you change to either no toolkit or lucid.

Just a little point on this: while abstractly desirable, the trend
seems to be in the other direction:

One strong evidence is application-side decorations. Yes, the toolkit
is supposed to take care of that. But the temptation for application
developers is enormous to "know better" here and there.

Currently I have the "pleasure" of working with Windows for a first
time in a long while, and the situation is dire.

Some applications (typically "old" ones, like the terminal) need a
click to get focus, that first click doesn't do anything else. Other
applications do something on the first click right away (the browser
selects the URL if you happen to click on the right place; some browser
"apps" do even much more -- one chat app I "have to use" puts you in
some answer mode). The "close" button on the browser's faux window
decorations disappears when you make the window too narrow (is it
that what they call "responsive design"?).

We have reached the point where some random javascript off the 'net
can and does override GUI conventions, and the trend will grow
stronger with time. The economy of the net is one of attention,
and apps are bound to compete with each other on this metric, too.

The worse part of it: people don't care. They adapt. Seems to be
a kind of Stockholm syndrome. I won't go deeper into that, since
I'm semi off topic already, but I find that deeply disturbing, as
if app developers were intentionally messing with user's brains.

Back to topic: yes, consistency across the desktop is desirable,
but to be taken with a grain of salt. Relevant actors don't seem
to care.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Eli Zaretskii]

> Date: Tue, 23 Aug 2022 06:44:50 +0200
> From: <tomas@tuxteam.de>
> 
> One strong evidence is application-side decorations. Yes, the toolkit
> is supposed to take care of that. But the temptation for application
> developers is enormous to "know better" here and there.

I indeed question the optimistic belief that system-wide conventions
are always better.  They might be in some basic stuff, like the outer
decorations of the GUI windows, but other than that...

> Currently I have the "pleasure" of working with Windows for a first
> time in a long while, and the situation is dire.
> 
> Some applications (typically "old" ones, like the terminal) need a
> click to get focus, that first click doesn't do anything else.

Jist FYI: that's configurable, if you want to change it (I don't).

> Other
> applications do something on the first click right away (the browser
> selects the URL if you happen to click on the right place; some browser
> "apps" do even much more -- one chat app I "have to use" puts you in
> some answer mode).

The solution, of course, is to always click only on the window
decorations, not inside the client area.  Then all the applications
will behave the same, because it isn't the app, it's the window
manager's behavior.

Alternatively, configure Windows to auto-focus a window when the mouse
pointer is over it for some predefined minimum time.  That's what I
do, and I never needed to look back.  (You can also auto-raise the
window at that time, but I don't: the whole point is to be able to
type into a window that is not on top.)

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

On Tue, Aug 23, 2022 at 02:45:24PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 23 Aug 2022 06:44:50 +0200
> > From: <tomas@tuxteam.de>
> > 
> > One strong evidence is application-side decorations. Yes, the toolkit
> > is supposed to take care of that. But the temptation for application
> > developers is enormous to "know better" here and there.
> 
> I indeed question the optimistic belief that system-wide conventions
> are always better.  They might be in some basic stuff, like the outer
> decorations of the GUI windows, but other than that...

Yes, but the "outer decorations" now belong to the application (the
browser, at least, is like that).

> > Currently I have the "pleasure" of working with Windows [...]
    [first click active]

> Jist FYI: that's configurable, if you want to change it (I don't).

Hm. On an application-by-application basis? But... good to know.

> > Other
> > applications do something on the first click right away (the browser
> > selects the URL if you happen to click on the right place; some browser
> > "apps" do even much more -- one chat app I "have to use" puts you in
> > some answer mode).
> 
> The solution, of course, is to always click only on the window
> decorations, not inside the client area.  Then all the applications
> will behave the same, because it isn't the app, it's the window
> manager's behavior.

But the problem is... the decoration area /is/ client area for those
more "modern" windows (e.g. the browser). And the javascript running
in the browser (the "app") has a say in how those things react.

I find myself searching for spots "between" the menus and the close
widget to land the click without creating havoc. And don't get me
started with scroll events, which can (and do) go to unfocused
windows. But that's not the topic here.

> Alternatively, configure Windows to auto-focus a window when the mouse
> pointer is over it for some predefined minimum time.  That's what I
> do, and I never needed to look back.  (You can also auto-raise the
> window at that time, but I don't: the whole point is to be able to
> type into a window that is not on top.)

Oh, point-to-focus, thanks for this :-)

I'm going to install Linux on the box (I've my boss's OK), but otherwise
I'd give it a try, so thanks for the hint!

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Eli Zaretskii]

> Date: Tue, 23 Aug 2022 14:02:21 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > I indeed question the optimistic belief that system-wide conventions
> > are always better.  They might be in some basic stuff, like the outer
> > decorations of the GUI windows, but other than that...
> 
> Yes, but the "outer decorations" now belong to the application

No, they don't.  Maybe you just aren't aware that those decorations
are all but invisible on latest Windows.  But they still exist, if you
know where they are...

> > > Currently I have the "pleasure" of working with Windows [...]
>     [first click active]
> 
> > Jist FYI: that's configurable, if you want to change it (I don't).
> 
> Hm. On an application-by-application basis?

No, for the console.

> > The solution, of course, is to always click only on the window
> > decorations, not inside the client area.  Then all the applications
> > will behave the same, because it isn't the app, it's the window
> > manager's behavior.
> 
> But the problem is... the decoration area /is/ client area for those
> more "modern" windows

No, see above.  Each window still has a border, albeit a thin and
basically invisible one.

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Tue, Aug 23, 2022 at 03:31:51PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 23 Aug 2022 14:02:21 +0200
> > From: tomas@tuxteam.de
> > Cc: emacs-devel@gnu.org
> > 
> > > I indeed question the optimistic belief that system-wide conventions
> > > are always better.  They might be in some basic stuff, like the outer
> > > decorations of the GUI windows, but other than that...
> > 
> > Yes, but the "outer decorations" now belong to the application
> 
> No, they don't.  Maybe you just aren't aware that those decorations
> are all but invisible on latest Windows.  But they still exist, if you
> know where they are...

Ah, so those I see belong to the application, and those I don't are
the "real" ones. Sounds plausible ;-)

[...]

> No, see above.  Each window still has a border, albeit a thin and
> basically invisible one.

That would mean I "just" have to learn clicking onto the one-pixel wide
"real" window frame. I'll try :)

(But actually, I'm looking forward to when this box runs FVWM ;)

Cheers & thanks for the insights.

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Eli Zaretskii]

> Date: Tue, 23 Aug 2022 14:48:26 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > No, see above.  Each window still has a border, albeit a thin and
> > basically invisible one.
> 
> That would mean I "just" have to learn clicking onto the one-pixel wide
> "real" window frame. I'll try :)

The shape of the mouse pointer changes when you are on the right spot,
so you could use that as an indication.

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Tue, Aug 23, 2022 at 04:22:51PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 23 Aug 2022 14:48:26 +0200
> > From: tomas@tuxteam.de
> > Cc: emacs-devel@gnu.org
> > 
> > > No, see above.  Each window still has a border, albeit a thin and
> > > basically invisible one.
> > 
> > That would mean I "just" have to learn clicking onto the one-pixel wide
> > "real" window frame. I'll try :)
> 
> The shape of the mouse pointer changes when you are on the right spot,
> so you could use that as an indication.

You mean... where I get those funky resize arrows? Yes, I see them. But
I don't see the other decorations hidden there :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Eli Zaretskii]

> Date: Tue, 23 Aug 2022 16:10:58 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> On Tue, Aug 23, 2022 at 04:22:51PM +0300, Eli Zaretskii wrote:
> > > Date: Tue, 23 Aug 2022 14:48:26 +0200
> > > From: tomas@tuxteam.de
> > > Cc: emacs-devel@gnu.org
> > > 
> > > > No, see above.  Each window still has a border, albeit a thin and
> > > > basically invisible one.
> > > 
> > > That would mean I "just" have to learn clicking onto the one-pixel wide
> > > "real" window frame. I'll try :)
> > 
> > The shape of the mouse pointer changes when you are on the right spot,
> > so you could use that as an indication.
> 
> You mean... where I get those funky resize arrows? Yes, I see them. But
> I don't see the other decorations hidden there :-)

There are none, AFAIK.  Just the (invisible) border.

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Yuri Khan]

On Tue, 23 Aug 2022 at 20:23, Eli Zaretskii <eliz@gnu.org> wrote:

> The shape of the mouse pointer changes when you are on the right spot,
> so you could use that as an indication.

You must have a really steady hand if you can pixel-hunting resize
edges and activate windows by clicking those. If I tried that, I’d
overshoot the edge half the time, and ruin the window size by
accidentally moving the mouse before releasing the button in half the
remaining cases.

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Tue, 23 Aug 2022 23:38:56 +0700
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> 
> On Tue, 23 Aug 2022 at 20:23, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The shape of the mouse pointer changes when you are on the right spot,
> > so you could use that as an indication.
> 
> You must have a really steady hand if you can pixel-hunting resize
> edges and activate windows by clicking those.

No, I configured Windows to give focus automatically, as I said
up-thread.  So I don't have this problem, except on other people's
computers.

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

On Tue, Aug 23, 2022 at 07:57:45PM +0300, Eli Zaretskii wrote:
> > From: Yuri Khan <yuri.v.khan@gmail.com>
> > Date: Tue, 23 Aug 2022 23:38:56 +0700
> > Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> > 
> > On Tue, 23 Aug 2022 at 20:23, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > > The shape of the mouse pointer changes when you are on the right spot,
> > > so you could use that as an indication.
> > 
> > You must have a really steady hand if you can pixel-hunting resize
> > edges and activate windows by clicking those.

I adapted (see below).

> No, I configured Windows to give focus automatically, as I said
> up-thread.  So I don't have this problem, except on other people's
> computers.

Since I don't plan to "stay" on Windows, I didn't want to invest
too much into customizing it. Good to know that it can be done,
though.

What I wanted to point out was rather what such a learning
experience does to the user. Jumping through seemingly gratuitous
hoops does something with one's brains.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Eli Zaretskii]

> Date: Wed, 24 Aug 2022 06:23:20 +0200
> From: tomas@tuxteam.de
> Cc: Yuri Khan <yuri.v.khan@gmail.com>, emacs-devel@gnu.org
> 
> What I wanted to point out was rather what such a learning
> experience does to the user. Jumping through seemingly gratuitous
> hoops does something with one's brains.

Your views and impressions are obviously skewed by your prior
experience.  (As are those of every one of us.)  Most people around me
have no problems of the kind you described, none whatsoever.  It's a
simple matter of getting used to something.

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I indeed question the optimistic belief that system-wide conventions
> are always better.  They might be in some basic stuff, like the outer
> decorations of the GUI windows, but other than that...

Until the GTK and GNOME developers declare that they know better, and
refuse to let the window manager draw window decorations...

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Until the GTK and GNOME developers declare that they know better, and
  > refuse to let the window manager draw window decorations...

If we maintain our version of GTK2, could we do that ourselves?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Consistent theme across the desktop [Re: Abysmal state of GTK build]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Tue, Aug 23, 2022 at 11:52:58PM -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Until the GTK and GNOME developers declare that they know better, and
>   > refuse to let the window manager draw window decorations...
> 
> If we maintain our version of GTK2, could we do that ourselves?

This is a tall order. We'd have to find enough allies for it to be
feasible, I think.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Abysmal state of GTK build

[Dirk-Jan C. Binnema]

On Monday Aug 22 2022, Po Lu wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Like others in this thread, I don't use the menu-bar, toolbar,
>> scroll-bars etc, so toolkit seems somewhat irrelevant (I have to do an
>> M-x version to see which one I'm using!). I build using lucid as that
>> seemed like a better choice than gtk and I use xfce rather than gnome as
>> my desktop environment (and sometimes stumpwm).
>
> [...]
>
>> I suspect a part of the decision regarding which toolkit to build emacs
>> with for various distros probably relates to minimising the number of
>> toolkits to install. As Gnome seems to be the current 'default', gtk is
>> already installed, so will likely be a preferred choice unless some
>> other compelling reason is given.
>
> The problem here is not a stylistic issue.  I want to disable the GTK
> build by default because it leads to serious problems for users, up to
> and including crashes.

Does this apply to pgtk as well?

TBH, this whole thread sounds needlessly alarmist.

The various GTK builds have been working fine for me and apparently the
majority of emacs users on GNU/Linux. "Abysmal" does not describe that
all all.

There have been grumblings about scenarios that GTK doesn't implement
correctly or at all, and there were some big warning for that (there
still may be). It seems we now emacs is adding a new such scenario
(XInput2), while the GTK developers have lost some interest in X11 -- it
seems we should just not enable XInput2 in that case.

I'd actually hope we'd be able to do it _more_ with GTK, such as having
GTK tabs, using the header bar, etc., where emacs currently looks rather
antiquated.

Kind regards,
Dirk.


-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Re: Abysmal state of GTK build

[Po Lu]

"Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl> writes:

> Does this apply to pgtk as well?

PGTK has other problems on the input and selection side of things, and
shouldn't be used on X at all.  Try to select a large chunk of text in
the PGTK build running under X (xdisp.c immediately comes to mind), and
insert it into another program with Button2.  It will immediately crash
with an X Windows error.

> TBH, this whole thread sounds needlessly alarmist.

I'd have said the same until I actually started working on the GTK
build, which was in an even worse state several months ago.  For
example, because many people do not use toolkit widgets in Emacs
seriously, and GTK changes too quickly, a bug where moving the mouse
wheel on the scroll bar does nothing was not found in time to be fixed
in Emacs 28.

Seriously, folks, if you don't use the scroll bar enough to find such an
obvious bug, you might as well use the a build of Emacs with non-toolkit
scroll bars.

> The various GTK builds have been working fine for me and apparently the
> majority of emacs users on GNU/Linux. "Abysmal" does not describe that
> all all.

Okay, then please show another build of Emacs where opening Dired on a
relatively small frame prints warning messages to stdout, and
potentially resizes the frame to fit the menu bar.  Or resizing a frame
from the top left corner causes the bottom right corner of the frame to
lag behind the resize.

All of these might seem to be minor nuances, but they leave bad tastes
in users mouths.  The users then place the blame on us, and ask: "why
can't Emacs behave as nicely as other editors?"  (The answer is really
that the other editors use some other toolkit.)

> There have been grumblings about scenarios that GTK doesn't implement
> correctly or at all, and there were some big warning for that (there
> still may be). It seems we now emacs is adding a new such scenario
> (XInput2), while the GTK developers have lost some interest in X11 -- it
> seems we should just not enable XInput2 in that case.

It seems to me that the same crowd asking for various "modern" GTK
features also want features like pixel-scroll-precision-mode and monitor
refresh synchronization, which cause crashes or don't work on GTK.  We
are then blamed for the feature not working there as a result of bugs or
misdesigns in GTK.

In any case, there is no excuse for GTK to have buggy XInput 2 support,
considering that it used to be something that we did not support,
requiring various workarounds to explictly disable in GTK, and is
mentioned in the first few paragraphs of the GTK+ 2 to 3 migration
guidelines.

I only found out about this particular crash investigating bug#56879,
but there are many more issues, some of which are more insidious than
simple crashes.

> I'd actually hope we'd be able to do it _more_ with GTK, such as having
> GTK tabs, using the header bar, etc., where emacs currently looks rather
> antiquated.

Then we'd be dealing with GTK randomly resizing our frames to fit the
tab bar in addition to the menu bar.  Or the authors of the GNOME Human
Interface Guidelines declaring tab bars against the law at some point in
the future.  No thanks.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 22 Aug 2022 20:10:16 +0800
> 
> "Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl> writes:
> 
> > Does this apply to pgtk as well?
> 
> PGTK has other problems on the input and selection side of things, and
> shouldn't be used on X at all.

What about PGTK build on Wayland, not on X?

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> What about PGTK build on Wayland, not on X?

It has the same input-related problems to a much lesser degree, and
selections work fine.  And either way, it's the only choice on Wayland.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: djcb@djcbsoftware.nl,  emacs-devel@gnu.org
> Date: Mon, 22 Aug 2022 20:59:38 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What about PGTK build on Wayland, not on X?
> 
> It has the same input-related problems to a much lesser degree, and
> selections work fine.  And either way, it's the only choice on Wayland.

Does it cause crashes?

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: djcb@djcbsoftware.nl,  emacs-devel@gnu.org
>> Date: Mon, 22 Aug 2022 20:59:38 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > What about PGTK build on Wayland, not on X?
>> 
>> It has the same input-related problems to a much lesser degree, and
>> selections work fine.  And either way, it's the only choice on Wayland.
>
> Does it cause crashes?

No, but it causes things like bug#53200, where C-S-u is reported as C-u.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: djcb@djcbsoftware.nl,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 08:42:59 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: djcb@djcbsoftware.nl,  emacs-devel@gnu.org
> >> Date: Mon, 22 Aug 2022 20:59:38 +0800
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > What about PGTK build on Wayland, not on X?
> >> 
> >> It has the same input-related problems to a much lesser degree, and
> >> selections work fine.  And either way, it's the only choice on Wayland.
> >
> > Does it cause crashes?
> 
> No, but it causes things like bug#53200, where C-S-u is reported as C-u.

That's much less of a catastrophe, IMO, and could be alleviated by
some PGTK-specific bindings where these cases matter to us.

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That's much less of a catastrophe, IMO, and could be alleviated by
> some PGTK-specific bindings where these cases matter to us.

Yes, which is why it's currently very adequate for its intended use of
Wayland support.

Re: Abysmal state of GTK build

[Yilkal Argaw]

> Po Lu <luangruo@yahoo.com> Unsubscribe
>
> Aug 21, 2022, 2:06 PM (2 days ago)
>
>
> to emacs-devel
> Users of the GTK 3 build experience many, many problems.  The most
> recent such problem is bug#56869, which is definitely a bug in GTK.
>
> Taking into account the very low quality of the GDK X11 backend, which
> is not seeing active maintenance, shouldn't the build default to some
> other toolkit such as Motif, or even better, no toolkit at all?
>
> Especially considering that a GTK developer (the tail) wants to remove
> support for X11 (the dog) in future releases of GTK:
>
>  https://gitlab.gnome.org/GNOME/gtk/-/issues/5004


I recently tried to investigate this issue so I configured emacs with
the "with-x-toolkit=no" option. The thing that bothered me more than
dated look was the fact that the mouse button behaviours (clicks
doubleclicks and whatnot) do not work like many modern users have
gotten used to. I am of that generation who learned computing from in
windows 2000 era so holding the click button to navigate through menu
entries was very confusing. I know this behaviour dates back in the
history of X and that programs like xterm use it but I would think
making the default might turn out to be a lot more confusing to new
users. This behaviour is also a bit hard to use with touch pads (since
many users just tap for clicks). I might be missing something so
correct me if I am wrong.

with regards
Yilkal A.

On Tue, Aug 23, 2022 at 3:44 AM Po Lu <luangruo@yahoo.com> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: djcb@djcbsoftware.nl,  emacs-devel@gnu.org
> >> Date: Mon, 22 Aug 2022 20:59:38 +0800
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > What about PGTK build on Wayland, not on X?
> >>
> >> It has the same input-related problems to a much lesser degree, and
> >> selections work fine.  And either way, it's the only choice on Wayland.
> >
> > Does it cause crashes?
>
> No, but it causes things like bug#53200, where C-S-u is reported as C-u.
>

Re: Abysmal state of GTK build

[Stefan Monnier]

> I recently tried to investigate this issue so I configured emacs with
> the "with-x-toolkit=no" option. The thing that bothered me more than
> dated look was the fact that the mouse button behaviours (clicks
> doubleclicks and whatnot) do not work like many modern users have
> gotten used to.

That's just a reflection of the fact that `with-x-toolkit=no` has not
received much love, except to accommodate those people who use it
because they prefer its behavior.

If we want to make it the default, we need to improve its behavior to
accommodate those who prefer behaviors like that of Gtk.


        Stefan

Re: Abysmal state of GTK build

[Po Lu]

Yilkal Argaw <yilkalargawworkneh@gmail.com> writes:

> I recently tried to investigate this issue so I configured emacs with
> the "with-x-toolkit=no" option. The thing that bothered me more than
> dated look was the fact that the mouse button behaviours (clicks
> doubleclicks and whatnot) do not work like many modern users have
> gotten used to. I am of that generation who learned computing from in
> windows 2000 era so holding the click button to navigate through menu
> entries was very confusing. I know this behaviour dates back in the
> history of X and that programs like xterm use it but I would think
> making the default might turn out to be a lot more confusing to new
> users. This behaviour is also a bit hard to use with touch pads (since
> many users just tap for clicks). I might be missing something so
> correct me if I am wrong.

Clicks and double clicks should work the same way as they do on any
other build, right?

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 22 Aug 2022 20:10:16 +0800
> 
> > There have been grumblings about scenarios that GTK doesn't implement
> > correctly or at all, and there were some big warning for that (there
> > still may be). It seems we now emacs is adding a new such scenario
> > (XInput2), while the GTK developers have lost some interest in X11 -- it
> > seems we should just not enable XInput2 in that case.
> 
> It seems to me that the same crowd asking for various "modern" GTK
> features also want features like pixel-scroll-precision-mode and monitor
> refresh synchronization, which cause crashes or don't work on GTK.  We
> are then blamed for the feature not working there as a result of bugs or
> misdesigns in GTK.
> 
> In any case, there is no excuse for GTK to have buggy XInput 2 support,
> considering that it used to be something that we did not support,
> requiring various workarounds to explictly disable in GTK, and is
> mentioned in the first few paragraphs of the GTK+ 2 to 3 migration
> guidelines.

What is your opinion on defaulting the GTK build to be without
XInput2?  Since that option causes crashes, it sounds to me like a
good compromise to leave the GTK build (by default) without the
XInput2 niceties, providing an opt-in configure-time switch to use
XInput2.  This will allow people who don't mind an occasional crash,
or can avoid that procedurally, to have the XInput2 features, while at
the same time protecting the innocent.

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> What is your opinion on defaulting the GTK build to be without
> XInput2?

It would mean leaving the default build without several features.  Since
those features will be missing by default, most users will not know of
them, and they will end up not being useful.  Which is why I think the
default should be one of the Lucid, Motif, or no tookit builds, which
both provide those features and avoid the crashes.

I really cannot understand the objection to such a default based on the
set of tool bar icons available there.  If they are such a big problem,
the icons used in the existing GTK build can be imported right now, as
they are under the same GPL v2 license that the current tool bar icons
in etc/images use.  But all of that smells of putting looks above
usefulness, a godforsaken plague of modern software that Emacs has not
yet succumb to.

Re: Abysmal state of GTK build

[Dmitry Gutov]

On 22.08.2022 16:03, Po Lu wrote:
> I really cannot understand the objection to such a default based on the
> set of tool bar icons available there.

Don't forget HiDPI support.

> If they are such a big problem,
> the icons used in the existing GTK build can be imported right now, as
> they are under the same GPL v2 license that the current tool bar icons
> in etc/images use.

The GTK3 build is special in that it uses the icons set up by the GTK 
user theme. So there is no one specific set.

But we could import one of them, for instance, from the default GNOME 3 
theme. The license is probably good enough.

> But all of that smells of putting looks above
> usefulness, a godforsaken plague of modern software that Emacs has not
> yet succumb to.

We do want new users to try Emacs and decide to stick with it, don't we?

Re: Abysmal state of GTK build

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Don't forget HiDPI support.

Lars says it works well enough on the Lucid build, at least as well as
the rest of Emacs does at present.  Borders and box faces don't scale
but there is nothing that can be done about that at present.

> We do want new users to try Emacs and decide to stick with it, don't we?

Right, and one way to do that is to provide them with a build where the
frame does not randomly resize itself upon entering a Dired buffer, or
where the `scroll-bar-width' frame parameter actually behaves as
documented instead of just flickering, or where an X disconnect does not
crash Emacs.

Re: Abysmal state of GTK build

[Dmitry Gutov]

On 23.08.2022 03:45, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> Don't forget HiDPI support.
> Lars says it works well enough on the Lucid build, at least as well as
> the rest of Emacs does at present.  Borders and box faces don't scale
> but there is nothing that can be done about that at present.

Huh, indeed. I guess my impression of it was old.

But the scrollbars look odd, and the icons and the grey background make 
the program look dated. Not a problem for me personally: I disable both.

>> We do want new users to try Emacs and decide to stick with it, don't we?
> Right, and one way to do that is to provide them with a build where the
> frame does not randomly resize itself upon entering a Dired buffer, or
> where the `scroll-bar-width' frame parameter actually behaves as
> documented instead of just flickering, or where an X disconnect does not
> crash Emacs.

Well, yes, but also better looks.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: djcb@djcbsoftware.nl,  emacs-devel@gnu.org
> Date: Mon, 22 Aug 2022 21:03:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What is your opinion on defaulting the GTK build to be without
> > XInput2?
> 
> It would mean leaving the default build without several features.  Since
> those features will be missing by default, most users will not know of
> them, and they will end up not being useful.

But since we are talking about making GTK not the default build, that
should be okay, I think.

> Which is why I think the default should be one of the Lucid, Motif,
> or no tookit builds, which both provide those features and avoid the
> crashes.

I'm asking whether making GTK not the default build, and _also_ making
the GTK build by default not use XInput2, sounds OK?

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> It would mean leaving the default build without several features.  Since
>> those features will be missing by default, most users will not know of
>> them, and they will end up not being useful.
>
> But since we are talking about making GTK not the default build, that
> should be okay, I think.

Yes, that sounds okay.

Re: Abysmal state of GTK build

[Lynn Winebarger]

On Mon, Aug 22, 2022 at 8:12 AM Po Lu <luangruo@yahoo.com> wrote:
> "Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl> writes:
> > TBH, this whole thread sounds needlessly alarmist.
I use the GTK build, and I've experienced the occasional odd crash
with messages indicating there was a problem in GTK.  I don't even use
X forwarding.

> > There have been grumblings about scenarios that GTK doesn't implement
> > correctly or at all, and there were some big warning for that (there
> > still may be). It seems we now emacs is adding a new such scenario
> > (XInput2), while the GTK developers have lost some interest in X11 -- it
> > seems we should just not enable XInput2 in that case.
>
> It seems to me that the same crowd asking for various "modern" GTK
> features also want features like pixel-scroll-precision-mode and monitor
> refresh synchronization, which cause crashes or don't work on GTK.  We
> are then blamed for the feature not working there as a result of bugs or
> misdesigns in GTK.

I have no expertise in implementing graphical interfaces, but as a
user I prefer applications to make use of the styling/interface
behavior from the main GUI, at least if I'm using something like
GNOME/KDE/XFCE.  That's part of *why* you choose such a GUI.  If the
interface is too dissonant with what I expect, I probably won't notice
whether something like "pixel-scroll-precision-mode" exists.

> Then we'd be dealing with GTK randomly resizing our frames to fit the
> tab bar in addition to the menu bar.  Or the authors of the GNOME Human
> Interface Guidelines declaring tab bars against the law at some point in
> the future.  No thanks.
It seems like you're missing the point.  If I'm a user of GNOME after
they do that, it probably means I am ok with prohibiting tab bars.  Or
I shouldn't be using that version of GNOME.  The choice of GUI
implicitly signals user preferences about the features they want and
don't want.  What's the issue with deferring to that?
That Haiku interface sounds interesting. It would be nice to have an
Emacs that cooperates with the GUI model of events via threaded
processing, instead of insisting on the same basic event loop used for
terminal-based interaction.
Of course, it's not like I'm offering to do any development.  It's not
really my area.

Lynn

Re: Abysmal state of GTK build

[Dirk-Jan C. Binnema]

Thanks for the detailed response.

On Monday Aug 22 2022, Po Lu wrote:

> "Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl> writes:
>
>> Does this apply to pgtk as well?
>
> PGTK has other problems on the input and selection side of things, and
> shouldn't be used on X at all.  Try to select a large chunk of text in
> the PGTK build running under X (xdisp.c immediately comes to mind), and
> insert it into another program with Button2.  It will immediately crash
> with an X Windows error.

So it does not apply to pgtk on Wayland? What about on X?

I don't use X, but I can't remember problems copy-pasting between other
Gtk program (say, GEdit and gnome-builder). What is emacs doing
differently?

>> TBH, this whole thread sounds needlessly alarmist.
>
> I'd have said the same until I actually started working on the GTK
> build, which was in an even worse state several months ago.

I've seen some old grumblings and apparently some new problem with
Xinput2-related code. But I've been happily using gtk-based emacs since
20 years or so? So, I find it strange if it suddenly changed to
"abysmal" and selected for immediate demotion to be non-default.

> It seems to me that the same crowd asking for various "modern" GTK
> features also want features like pixel-scroll-precision-mode and monitor
> refresh synchronization, which cause crashes or don't work on GTK.  We
> are then blamed for the feature not working there as a result of bugs or
> misdesigns in GTK.

I'm not seeing any of that. What about Gimp & Inkscape -- don't they
support Xinput2?

> In any case, there is no excuse for GTK to have buggy XInput 2 support,
> considering that it used to be something that we did not support,
> requiring various workarounds to explictly disable in GTK, and is
> mentioned in the first few paragraphs of the GTK+ 2 to 3 migration
> guidelines.

There are always excuses for bugs of course :-) In this case it seems
that emacs exercises some old code in new ways, while the maintainers
are concentrating on Wayland. 

>> I'd actually hope we'd be able to do it _more_ with GTK, such as having
>> GTK tabs, using the header bar, etc., where emacs currently looks rather
>> antiquated.
>
> Then we'd be dealing with GTK randomly resizing our frames to fit the
> tab bar in addition to the menu bar.  Or the authors of the GNOME Human
> Interface Guidelines declaring tab bars against the law at some point in
> the future.  No thanks.

E.g. tab-usage like Gedit or Gnome Builder do it, would be a great
visual improvement IMHO. Or even Firefox's (which implemented their own
tabs I think?).

Anyway, thank you for your work... it is appreciated.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Re: Abysmal state of GTK build

[Po Lu]

"Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl> writes:

> So it does not apply to pgtk on Wayland? What about on X?

PGTK is not supported on X and does not run correctly there.

> I don't use X, but I can't remember problems copy-pasting between other
> Gtk program (say, GEdit and gnome-builder). What is emacs doing
> differently?

Emacs has higher requirements, since we perform selection encoding
ourselves with decades-old battle tested code in select.el.

> I've seen some old grumblings and apparently some new problem with
> Xinput2-related code. But I've been happily using gtk-based emacs since
> 20 years or so? So, I find it strange if it suddenly changed to
> "abysmal" and selected for immediate demotion to be non-default.

The changes happened gradually after GTK 3.4.  I guess people don't
notice gradual changes.

> I'm not seeing any of that. What about Gimp & Inkscape -- don't they
> support Xinput2?

The GIMP still uses GTK+ 2.x due to difficulties porting to GTK 3.
It does not use XInput 2.

Inkscape uses GTK 3 and suffers from the same crashes that Emacs does if
the trackpad is disabled upon typing.  Its usage patterns differ from
Emacs's, so the bug occurs there less.  After all, people do not type
much in a vector graphics editor.

> There are always excuses for bugs of course :-) In this case it seems
> that emacs exercises some old code in new ways, while the maintainers
> are concentrating on Wayland. 

The point is, we support X11, and if GTK cannot properly support X11,
the GTK build should not be the default.  The priorities of the GTK
maintainers are not an excuse.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The regular GTK build of Emacs will not run on GNOME Wayland either.

1. Is this something that we could fix?
2. Is this something that the GTK develoers could fix?

  > People who want to use Wayland should use the different PGTK build instead.

Would it make sense for specifying GTK, on a system which uses Wayland,
to select the PGTK build automatically instead of the GTK build?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> 1. Is this something that we could fix?

No, not really.

> 2. Is this something that the GTK develoers could fix?

No.

> Would it make sense for specifying GTK, on a system which uses Wayland,
> to select the PGTK build automatically instead of the GTK build?

You mean, at build-time?  Yes, that would make sense.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Would it make sense for specifying GTK, on a system which uses Wayland,
  > > to select the PGTK build automatically instead of the GTK build?

  > You mean, at build-time?  Yes, that would make sense.

What is the relationship of PGTK to GTK?  Is PGTK as software
similar to GTK?  If so, which version of GTK is it similar to?
Is it going to cause us problems like the ones GTK 3 is causing us?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> What is the relationship of PGTK to GTK?  Is PGTK as software
> similar to GTK?  If so, which version of GTK is it similar to?
> Is it going to cause us problems like the ones GTK 3 is causing us?

PGTK is a build of Emacs using GTK 3 without any Xlib-specific code.  It
is used to support the Wayland window system, not X.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, and we have to fix bug#56869 by working around the problem, as we
> do with all OS/library-related issues.  Just because it's something else
> that's "wrong" doesn't mean we can ignore the issue.

We cannot work around the problem because it is a NULL-pointer
dereference in GTK, caused by it mishandling several events
consecutively.

In general, Emacs can only prevent GTK from handling certain events.  If
it handles an event that it must handle (in this case,
XI_HierarchyChange) incorrectly, and that causes GTK to later
dereference NULL, there is nothing that Emacs can do.  Just like what
happens when GTK calls _exit under our nose.

> Anyway, I'm all in favour of defaulting to a no-toolkit build (across
> all systems -- the astounding success of VS Code has show that having a
> consistent look across systems is much more important than respecting
> the look of the OS).

I doubt that it would even be possible at all with our manpower to
implement "our own toolkit" on all platforms.  Especially on systems
like macOS, where AFAICT the system tries its best to prevent you from
implementing certain things yourself (such as tooltips and popup menus,
the former proved to be a royal pain in the neck earlier.)

Besides, how is that related to the success of Microsoft's VS Code?  I
think it is more related to how much support it gets from toolchain
developers, caused by Microsoft bundling it with their GitHub platform,
much like they bundled MSIE with Windows 95.  Cargo culting their choice
of toolkit will not do us much good.

> But we have to fix the no-toolkit look before we can contemplate that.
>
> 1) New toolbar icons:
>
>   
>
>
>
>
> We need somebody, preferably a designer, to put together a set of
> consistent (and pretty) toolbar icons.

The toolbar icons come from GNOME 2.x, so they are already consistent
and (mostly) put together by designers.  Aside from the ugly cross icon,
which really has to go.

> 2) Background glitches:
>
> I've got *background: black, and that makes "emacs -Q" look like this:
>
>
>
>
>
>
> That has to be fixed.

Just turn off the internal border, or specify the color of the internal
border in your X resources.  The default size of the internal border is
intentionally different across different builds and window systems, to
make up for different looking decorations.

> 3) Menu bar font:
>
>
>
>
> Must be proportional to not look like an artefact of the 80s.

I'd be glad if someone worked on that.  At the same time, we could make
RTL text work there as well.

> 4) HiDPI problems in the menus: The menus are unreadably small on a
> HiDPI display.

The fix is to specify a larger font for the menus.  But see below for
more problems with the oldXMenu library:

> 5) The scroll bar has to be fixed to work as modern scroll bars to, not
> emulate the actions of an 80s Xterm.  I.e., you have to be able to drag
> the scrool widget, and click above and below it, and have the thing
> happen that normal users expect.

I disagree, but that behavior should be made customizable.  The
"no-toolkit" scroll bar in general is a big hack that is not portable to
platforms other than X.

> Once those five things are in place, we should default to a no-toolkit
> build, which will give us a lot more control of Emacs behaviour, and not
> rely on odd tics in each toolkit, and in addition, allow
> daemon/multi-display shutdown to work reliably.

The no-toolkit build can not work on any other platform other than X.
The scroll bars are implemented by Emacs itself in a very non-portable
way, and the menus are implemented by the old XMenu library that came
with X10 and early X11 releases.

All of that amounts to a large amount of code that is very difficult to
replicate on other platforms.

Thanks.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 21 Aug 2022 21:30:38 +0800
> 
> I doubt that it would even be possible at all with our manpower to
> implement "our own toolkit" on all platforms.

Maybe someone should take another look at a possible use of Qt?

In any case, the MS-Windows port is not part of this dilemma: we are
using the only system "toolkit" available there, so we are quite
consistent with the look-and-feel of other GUI apps, and lately
extended our support for system-wide toolkit themes as well.

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe someone should take another look at a possible use of Qt?

I'm not opposed to adding a Qt port and making it the default if it
works well enough (tho I have no expertise in that field), but wasn't
there a great deal of drama between the KDE developers and the Qt
Company recently that might render it unsuitable for our use?

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sun, 21 Aug 2022 21:41:23 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe someone should take another look at a possible use of Qt?
> 
> I'm not opposed to adding a Qt port and making it the default if it
> works well enough (tho I have no expertise in that field), but wasn't
> there a great deal of drama between the KDE developers and the Qt
> Company recently that might render it unsuitable for our use?

I don't know.  I said "take another look" because I don't know the
outcome.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe someone should take another look at a possible use of Qt?

I haven't kept up with Qt development at all -- but at one point, using
Qt required using C++, I think.  Is that still the case?

(Not that that's necessarily a deal breaker.)

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Po Lu <luangruo@yahoo.com>,  emacs-devel@gnu.org
> Date: Sun, 21 Aug 2022 15:47:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe someone should take another look at a possible use of Qt?
> 
> I haven't kept up with Qt development at all -- but at one point, using
> Qt required using C++, I think.  Is that still the case?

Yes, AFAIK.  But AFAIU it should be possible to call C++ functions
from a C program, given enough glue.

> (Not that that's necessarily a deal breaker.)

Exactly.  GCC already needs a C++ compiler to build, and so does GDB.
I see no problem requiring that for Emacs, if it will otherwise free
us from the GTK nightmares.

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, AFAIK.  But AFAIU it should be possible to call C++ functions
> from a C program, given enough glue.

The GUI parts requiring C++ can be neatly separated from the rest of the
C code through such glue.  That's how the Haiku port is implemented, see
src/haiku_support.cc (where the majority of the GUI code is
concentrated) and the callers of the extern "C" functions there in
haikuterm.c.

> Exactly.  GCC already needs a C++ compiler to build, and so does GDB.
> I see no problem requiring that for Emacs, if it will otherwise free
> us from the GTK nightmares.

Also, we don't have to require the Qt build.  It can just be the default
when the user has Qt and a C++ compiler, which everyone does these days.

Re: Abysmal state of GTK build

[Gerd Möllmann]

>> (Not that that's necessarily a deal breaker.)
> Exactly.  GCC already needs a C++ compiler to build, and so does GDB.
> I see no problem requiring that for Emacs

I think that would be a Good Thing, independent of Qt.

At least from my experience, using C++ can make it a lot easier to
structure large code bases, and thus make them more easily comprehendable.
Independently of what one thinks about the language itself :-).

But maybe I'm biased because I've been using C++ in commercial settings
a lot, in large projects, and for a very long time.  I'd be interested to
hear what other contributors think about this.

Re: Abysmal state of GTK build

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> At least from my experience, using C++ can make it a lot easier to
> structure large code bases, and thus make them more easily comprehendable.
> Independently of what one thinks about the language itself :-).
>
> But maybe I'm biased because I've been using C++ in commercial settings
> a lot, in large projects, and for a very long time.  I'd be interested to
> hear what other contributors think about this.

I think the exact opposite, mainly because I've been using C (as opposed
to C++) in similar settings, also with large projects.

Haven't we already discussed this many times in the past?

Re: Abysmal state of GTK build

[Gerd Möllmann]

> Haven't we already discussed this many times in the past?

I couldn't find it on emacs-devel, searching for "C++", and going
back to 2018.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> But maybe I'm biased because I've been using C++ in commercial settings
> a lot, in large projects, and for a very long time.  I'd be interested to
> hear what other contributors think about this.

I don't thing reading/writing C++ would be a problem for most Emacs
contributors.  My main reservation is how slow compiling C++ code seems
to be -- whenever I'm building something written in C++ (especially if
it uses Qt, apparently) I schedule a couple of laps around the block to
have something to do while waiting.

Re: Abysmal state of GTK build

[Gerd Möllmann]

On 22-08-23 11:39 , Lars Ingebrigtsen wrote:
> I don't thing reading/writing C++ would be a problem for most Emacs
> contributors.  My main reservation is how slow compiling C++ code seems
> to be -- whenever I'm building something written in C++ (especially if
> it uses Qt, apparently) I schedule a couple of laps around the block to
> have something to do while waiting.

Yeah, that can happen for large stuff with Rust, erm, I meant C++ :-).

OTOH, my impression so far with building contemporary Emacs is that the 
non-src part takes most of the time.

YYMV, I guess.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> OTOH, my impression so far with building contemporary Emacs is that
> the non-src part takes most of the time.

Yup.  If I remember correctly from last time I looked at this, with a
"make -j32" on a modern AMD machine, the build takes 65 seconds in
total, and of that 10 seconds are .c compilation, 20 seconds are
./configure, 5 seconds are info and 30 seconds are Lisp files.

The most recalcitrant thing is ./configure, of course -- it's
single-threaded.  Which is just sad.  Most of what it does is eminently
multi-threadable -- I'd guesstimate that 90% of the tests are
independent and could well be run in parallel.  Last time I googled
this, there were no plans to make autoconf parallel-capable.

I wonder whether anybody has looked into switching to a different build
system?

Re: Abysmal state of GTK build

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I wonder whether anybody has looked into switching to a different build
> system?

Long time ago I volunteered to create a CMake-based build system and
even experimented a bit to the point of dumping emacs. Almost all of the
work consisted on implementing the platform checks.

CMake has the advantage of supporting multiple "backends" for the build
phase, and `ninja' provides a significant speed-up over `make' on large
projects.

For the platform tests, in my experience CMake is faster than the
autotools, but it still works single-threaded.

Apart from better performance, CMake would simplify the scripts a great
deal.

I'm well aware that there are strong reasons of social nature against a
change like this.

Re: Alternative build systems (Was: Abysmal state of GTK build)

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 23 Aug 2022 17:29:46 +0200
> 
> Apart from better performance, CMake would simplify the scripts a great
> deal.

Not IME, not with the many complications and different configurations
we support.  E.g., does Gnulib support CMake builds?

Re: Alternative build systems

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Apart from better performance, CMake would simplify the scripts a great
>> deal.
>
> Not IME, not with the many complications and different configurations
> we support.  E.g., does Gnulib support CMake builds?

When I made the CMake build system for LLVM/Clang, it was about 1.5
orders of magnitude less verbose than the autoconf-based system for
feature parity.

CMake has the advantage of being procedural (like an ordinary scripting
language) and declarative (like `make'). This makes possible to use a
high level of abstraction that helps a lot when dealing with complexity.

For the Gnulib question, I can't answer, I don't know what it involves.
A quick web search says that Gnulib is tightly tied with autoconf and
messages like this are a bit gloomy:

https://lists.gnu.org/archive/html/bug-gnulib/2019-08/msg00091.html

Re: Alternative build systems

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 23 Aug 2022 18:36:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Apart from better performance, CMake would simplify the scripts a great
> >> deal.
> >
> > Not IME, not with the many complications and different configurations
> > we support.  E.g., does Gnulib support CMake builds?
> 
> When I made the CMake build system for LLVM/Clang, it was about 1.5
> orders of magnitude less verbose than the autoconf-based system for
> feature parity.

No one says you'd see anything like that with Emacs.  Emacs is not a
compiler system.

> CMake has the advantage of being procedural (like an ordinary scripting
> language) and declarative (like `make'). This makes possible to use a
> high level of abstraction that helps a lot when dealing with complexity.

Sorry, that's not my experience.  In the few cases where I needed to
tweak a CMake build (admittedly, nowhere as complex as Clang), I found
myself battling the same kind of stuff as with Autoconf: a huge
library of macros, variables, and settings.  Moreover, quite a few of
those are semi-documented in semi-comprehensible way.  The moment you
step 1/2" outside of the "usual" stuff, you are on your own.

> For the Gnulib question, I can't answer, I don't know what it involves.
> A quick web search says that Gnulib is tightly tied with autoconf and
> messages like this are a bit gloomy:
> 
> https://lists.gnu.org/archive/html/bug-gnulib/2019-08/msg00091.html

I know, right?  This is just an example of the problems we'd need to
deal with.  (Does CMake support Emacs Lisp compilation? does it know
about *.elc and *.eln files? does it know about emacs.pdmp? does it
know about installing programs like Emacs? etc. etc.)

Re: Alternative build systems

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> When I made the CMake build system for LLVM/Clang, it was about 1.5
>> orders of magnitude less verbose than the autoconf-based system for
>> feature parity.
>
> No one says you'd see anything like that with Emacs.  Emacs is not a
> compiler system.

Indeed, probably less reduction is expected on Emacs' case because its
build requirements are way simpler than Clang/LLVM (which is much more
than a compiler, BTW.)

Or not, because even small autotools-based projects are overly verbose
and daunting.

>> CMake has the advantage of being procedural (like an ordinary scripting
>> language) and declarative (like `make'). This makes possible to use a
>> high level of abstraction that helps a lot when dealing with complexity.
>
> Sorry, that's not my experience.  In the few cases where I needed to
> tweak a CMake build (admittedly, nowhere as complex as Clang), I found
> myself battling the same kind of stuff as with Autoconf: a huge
> library of macros, variables, and settings.  Moreover, quite a few of
> those are semi-documented in semi-comprehensible way.  The moment you
> step 1/2" outside of the "usual" stuff, you are on your own.

At least CMake and other modern build systems grants you a high degree
of freedom around how to organize your build specification. You can
write obfuscated code on any language, but some languages are more
convenient than others when a hacker makes the effort of writing easily
understandable code.

>> For the Gnulib question, I can't answer, I don't know what it involves.
>> A quick web search says that Gnulib is tightly tied with autoconf and
>> messages like this are a bit gloomy:
>> 
>> https://lists.gnu.org/archive/html/bug-gnulib/2019-08/msg00091.html
>
> I know, right?  This is just an example of the problems we'd need to
> deal with.  (Does CMake support Emacs Lisp compilation? does it know
> about *.elc and *.eln files? does it know about emacs.pdmp? does it
> know about installing programs like Emacs? etc. etc.)

Teaching all those things to CMake is trivial. Adding support for a
project that expects that you use their build system is another thing
entirely.

Re: Alternative build systems

[Po Lu]

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

> Indeed, probably less reduction is expected on Emacs' case because its
> build requirements are way simpler than Clang/LLVM (which is much more
> than a compiler, BTW.)

Its build requirements are much less simple.

In any case, a real improvement to the build system would be to make the
MS-DOS build use autoconf.  That way, we can have one build system, not
two (autoconf and GNU sed.)

Adding a third (CMake) is pointless and has nothing to do with the
matter at hand.  Qt support can be easily added without CMake.

Re: Abysmal state of GTK build

[Andrea Corallo]

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

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I wonder whether anybody has looked into switching to a different build
>> system?
>
> Long time ago I volunteered to create a CMake-based build system and
> even experimented a bit to the point of dumping emacs. Almost all of the
> work consisted on implementing the platform checks.
>
> CMake has the advantage of supporting multiple "backends" for the build
> phase, and `ninja' provides a significant speed-up over `make' on large
> projects.

Using ninja would translate into an hard dependency on python and I
don't think this is acceptable.  Also I'm not really sure ninja is
faster than make.

BR

  Andrea

Re: Abysmal state of GTK build

[Óscar Fuentes]

Andrea Corallo <akrl@sdf.org> writes:

>> CMake has the advantage of supporting multiple "backends" for the build
>> phase, and `ninja' provides a significant speed-up over `make' on large
>> projects.
>
> Using ninja would translate into an hard dependency on python and I
> don't think this is acceptable.  Also I'm not really sure ninja is
> faster than make.

Ninja does not depend on Python, maybe you are confusing it with some
other system.

The performance advantage of ninja over make is a well stablished fact.
For LLVM the difference is quite substantial, discovering that
precipitated the phasing out of the configure&make build and the
transition to the cmake-based build after years of being a second-class
system.

Re: Abysmal state of GTK build

[Visuwesh]

[புதன் ஆகஸ்ட் 24, 2022] Andrea Corallo wrote:

>
> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> I wonder whether anybody has looked into switching to a different build
>>> system?
>>
>> Long time ago I volunteered to create a CMake-based build system and
>> even experimented a bit to the point of dumping emacs. Almost all of the
>> work consisted on implementing the platform checks.
>>
>> CMake has the advantage of supporting multiple "backends" for the build
>> phase, and `ninja' provides a significant speed-up over `make' on large
>> projects.
>
> Using ninja would translate into an hard dependency on python and I
> don't think this is acceptable.  Also I'm not really sure ninja is
> faster than make.

FWIW, there is a C implementation of ninja called samurai:
https://github.com/michaelforney/samurai.

There is also a C implantation of meson called muon:
https://sr.ht/~lattis/muon/.

Re: Abysmal state of GTK build

[Po Lu]

Visuwesh <visuweshm@gmail.com> writes:

> FWIW, there is a C implementation of ninja called samurai:
> https://github.com/michaelforney/samurai.
>
> There is also a C implantation of meson called muon:
> https://sr.ht/~lattis/muon/.

Let's not hurry to replace autoconf.

autoconf and gmake work well enough -- they are part of the GNU project,
and allow GNU programs to be installed in a single, unified way:

  ./configure --prefix=/usr
  make install

It would be a shame for Emacs, the flagship of the GNU project, to
abandon the standard installation procedure for a GNU program.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eliz@gnu.org,  emacs-devel@gnu.org,  luangruo@yahoo.com
> Date: Tue, 23 Aug 2022 16:43:40 +0200
> 
> The most recalcitrant thing is ./configure, of course -- it's
> single-threaded.

Are you using -C ?  It makes the configure script fly.  Most of the
changes in the script nowadays don't need a full reconfiguration, and
seldom even add new variables.

> I wonder whether anybody has looked into switching to a different build
> system?

I tried some of them (not in Emacs), and my conclusion was that each
one needs to be studied and adapted, so switching means learning a
whole new language and set of tools and practices.  On top of that,
you'd have fewer people to ask and come to help if you have problems.

With -C, the configure step is so fast that I'm not sure I even want
to think about an alternative.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> The most recalcitrant thing is ./configure, of course -- it's
>> single-threaded.
>
> Are you using -C ? It makes the configure script fly.  Most of the
> changes in the script nowadays don't need a full reconfiguration, and
> seldom even add new variables.

This is with "make bootstrap" (or a fresh build), which I do a lot of.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org,  luangruo@yahoo.com
> Date: Tue, 23 Aug 2022 18:10:03 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The most recalcitrant thing is ./configure, of course -- it's
> >> single-threaded.
> >
> > Are you using -C ? It makes the configure script fly.  Most of the
> > changes in the script nowadays don't need a full reconfiguration, and
> > seldom even add new variables.
> 
> This is with "make bootstrap" (or a fresh build), which I do a lot of.

AFAIR, once you configure with -C, subsequent bootstraps also use -C
(I think).

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIR, once you configure with -C, subsequent bootstraps also use -C
> (I think).

I tried that now, but it didn't seem to work, so I guess that bootstrap
is deleting the cache file or something?  But having this would indeed
be very useful.  I.e., a variant of "make bootstrap" that has a very
fast ./configure -- that'd shave a third off the time it takes for me to
check for build issues.  A "bootstrap-fast" target or something?

Anybody know what it'd take to make that happen?

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org,  luangruo@yahoo.com
> Date: Wed, 24 Aug 2022 12:11:34 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIR, once you configure with -C, subsequent bootstraps also use -C
> > (I think).
> 
> I tried that now, but it didn't seem to work, so I guess that bootstrap
> is deleting the cache file or something?  But having this would indeed
> be very useful.  I.e., a variant of "make bootstrap" that has a very
> fast ./configure -- that'd shave a third off the time it takes for me to
> check for build issues.  A "bootstrap-fast" target or something?
> 
> Anybody know what it'd take to make that happen?

Don't delete config.cache?

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Don't delete config.cache?

Oh, that was simple.

Would a new target make sense, or a variable?  Like
"make FAST=true bootstrap"?  The latter seems slightly easier to
implement, and we're using variables to tweak other parts of the build.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org,  luangruo@yahoo.com
> Date: Wed, 24 Aug 2022 13:30:48 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Don't delete config.cache?
> 
> Oh, that was simple.
> 
> Would a new target make sense, or a variable?

Yes, I think so.

> Like "make FAST=true bootstrap"?  The latter seems slightly easier
> to implement, and we're using variables to tweak other parts of the
> build.

I think a variable should be fine, as this is mainly of interest for
people who bootstrap a lot.

Re: Abysmal state of GTK build

[Stefan Monnier]

> I think a variable should be fine, as this is mainly of interest for
> people who bootstrap a lot.

I don't see any need for a variable.  Those who want the `config.cache`
to be removed can either refrain from using one in the first place, or
remove it by hand.
This file is only used/generated upon explicit request.


        Stefan

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't see any need for a variable.  Those who want the `config.cache`
> to be removed can either refrain from using one in the first place, or
> remove it by hand.

It's nice that you can tell users to say "make bootstrap" and then the
tree returns to a known state (because we have many build issues that
are fixed by just that).  So I think we want to keep removing the
config.cache.

Re: Abysmal state of GTK build

[Stefan Monnier]

Lars Ingebrigtsen [2022-08-24 14:19:49] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I don't see any need for a variable.  Those who want the `config.cache`
>> to be removed can either refrain from using one in the first place, or
>> remove it by hand.
>
> It's nice that you can tell users to say "make bootstrap" and then the
> tree returns to a known state (because we have many build issues that
> are fixed by just that).  So I think we want to keep removing the
> config.cache.

Those users who use `-C` should know what to do.
And the argument against using a variable works the other way as well:
if you really want to keep your config.cache file, then just
use `--cache-file=config.cache.says`.


        Stefan

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Those users who use `-C` should know what to do.
> And the argument against using a variable works the other way as well:
> if you really want to keep your config.cache file, then just
> use `--cache-file=config.cache.says`.

That's a good point.  OK, I've moved the config.cache deletion from
bootstrap-clean to maintainer/extraclean.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  gerd.moellmann@gmail.com,
>   emacs-devel@gnu.org,  luangruo@yahoo.com
> Date: Wed, 24 Aug 2022 08:16:59 -0400
> 
> > I think a variable should be fine, as this is mainly of interest for
> > people who bootstrap a lot.
> 
> I don't see any need for a variable.  Those who want the `config.cache`
> to be removed can either refrain from using one in the first place, or
> remove it by hand.
> This file is only used/generated upon explicit request.

I think "make distclean" ought to remove the cache, and bootstrap
invokes that, either directly or indirectly.  So if we want to avoid
deleting the cache during bootstrap, we'd need to make it independent
of distclean.

And I'm not sure people who bootstrap won't be surprised by such a
change (but then I almost never bootstrap).

So, all in all, I think Lars's proposal is safer.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think "make distclean" ought to remove the cache, and bootstrap
> invokes that, either directly or indirectly.  So if we want to avoid
> deleting the cache during bootstrap, we'd need to make it independent
> of distclean.
>
> And I'm not sure people who bootstrap won't be surprised by such a
> change (but then I almost never bootstrap).
>
> So, all in all, I think Lars's proposal is safer.

Sorry, I made the change without reading all the messages in the thread.

These are also good points, so I've now reverted the change.  (Or rather,
I didn't push it yet, so I just unwound the commit.)

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Specifying an external cache file is also possible, of course, but it's
fiddly -- if you have many trees, you have to set up a system to have
one external cache file per tree.

So I've now pushed the FAST=true version.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I tried that now, but it didn't seem to work, so I guess that bootstrap
> is deleting the cache file or something?  But having this would indeed
> be very useful.  I.e., a variant of "make bootstrap" that has a very
> fast ./configure -- that'd shave a third off the time it takes for me to
> check for build issues.  A "bootstrap-fast" target or something?

I normally build with --cache-file=/tmp/ccache, which seems to survive
"make bootstrap".

Re: Abysmal state of GTK build

[Gerd Möllmann]

On 22-08-24 14:13 , Po Lu wrote:
> I normally build with --cache-file=/tmp/ccache, which seems to survive
> "make bootstrap".

Right, I've seen that in Makefile.in.  It deletes config.cache and not 
${cache_file}.  If that's intentional... :-).

Re: Abysmal state of GTK build

[Gerd Möllmann]

[-- Attachment #1.1.1: Type: text/plain, Size: 845 bytes --]


On 22-08-23 18:06 , Eli Zaretskii wrote:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: eliz@gnu.org,  emacs-devel@gnu.org,  luangruo@yahoo.com
>> Date: Tue, 23 Aug 2022 16:43:40 +0200
>>
>> The most recalcitrant thing is ./configure, of course -- it's
>> single-threaded.
> Are you using -C ?  It makes the configure script fly.  Most of the
> changes in the script nowadays don't need a full reconfiguration, and
> seldom even add new variables.
>
Interesting.   How are you using --config-cache?

I tried here two './configure --config-cache --with-native-compilation' 
in a row (no config.cache initially), and the second run failed because 
of something I don't understand.  Basically, it first says libgccjit.h 
found, and then fails because it can't find libgccjit.h.

Is this a bug, or am I doing it wrong?


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3211 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Abysmal state of GTK build

[Eli Zaretskii]

> Date: Wed, 24 Aug 2022 08:38:38 +0200
> Cc: emacs-devel@gnu.org, luangruo@yahoo.com
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
> On 22-08-23 18:06 , Eli Zaretskii wrote:
> >> From: Lars Ingebrigtsen <larsi@gnus.org>
> >> Cc: eliz@gnu.org,  emacs-devel@gnu.org,  luangruo@yahoo.com
> >> Date: Tue, 23 Aug 2022 16:43:40 +0200
> >>
> >> The most recalcitrant thing is ./configure, of course -- it's
> >> single-threaded.
> > Are you using -C ?  It makes the configure script fly.  Most of the
> > changes in the script nowadays don't need a full reconfiguration, and
> > seldom even add new variables.
> >
> Interesting.   How are you using --config-cache?

I just make a point of using it the first time I build a new
worktree.  Thereafter, I just use "make", and if it needs to re-run
configure, it uses -C automatically.

> I tried here two './configure --config-cache --with-native-compilation' 
> in a row (no config.cache initially), and the second run failed because 
> of something I don't understand.  Basically, it first says libgccjit.h 
> found, and then fails because it can't find libgccjit.h.
> 
> Is this a bug, or am I doing it wrong?

It's some kind of bug, but I'm not sure where.  I have this from time
to time on one particular system where I regularly build Emacs, but
not on others.  Usually, a second "make" right after that succeeds.

I always thought that it's because some system-wide snafu unrelated to
Emacs on that single system.  But now I'm not so sure.

(There's no longer any need to run 'configure', except, perhaps, the
first time you build a clean clone.  Just "make" does everything,
including running autogen.sh and the configure script, if needed.)

Re: Abysmal state of GTK build

[Gerd Möllmann]

On 22-08-24 13:08 , Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Interesting.   How are you using --config-cache?
> 
> I just make a point of using it the first time I build a new
> worktree.  Thereafter, I just use "make", and if it needs to re-run
> configure, it uses -C automatically.

Thanks for the explanation!

I see it now in Makefile, which has cache_file=...  After autogen.sh, 
it's /dev/null, but after an additional './configure --config-cache 
--with-native-compilation', cache_file equals config.cache.

I couldn't see a way to set the cache_file with autogen.sh, but anyway 
that's not too bad.

>> Is this a bug, or am I doing it wrong?
> 
> It's some kind of bug, but I'm not sure where.  I have this from time
> to time on one particular system where I regularly build Emacs, but
> not on others.  Usually, a second "make" right after that succeeds.
> 
> I always thought that it's because some system-wide snafu unrelated to
> Emacs on that single system.  But now I'm not so sure.

I guess it's indeed a bug.  When I

touch configure
make

it says

running CONFIG_SHELL=/bin/sh /bin/sh ./configure --config-cache 
--with-native-compilation --no-create --no-recursion

and fails in the same way as described before.

I'll submit a bug for that.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> Date: Wed, 24 Aug 2022 13:51:16 +0200
> Cc: larsi@gnus.org, emacs-devel@gnu.org, luangruo@yahoo.com
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
> > It's some kind of bug, but I'm not sure where.  I have this from time
> > to time on one particular system where I regularly build Emacs, but
> > not on others.  Usually, a second "make" right after that succeeds.
> > 
> > I always thought that it's because some system-wide snafu unrelated to
> > Emacs on that single system.  But now I'm not so sure.
> 
> I guess it's indeed a bug.  When I
> 
> touch configure
> make
> 
> it says
> 
> running CONFIG_SHELL=/bin/sh /bin/sh ./configure --config-cache 
> --with-native-compilation --no-create --no-recursion
> 
> and fails in the same way as described before.

And if you say "make" again, does it still fail?

It sounds like this is something macOS-specific, because for me on
that single system it fails only rarely, and the next "make" usually
succeeds.

Re: Abysmal state of GTK build

[Gerd Möllmann]

On 22-08-24 14:01 , Eli Zaretskii wrote:
> And if you say "make" again, does it still fail?

Yes.

> It sounds like this is something macOS-specific, because for me on
> that single system it fails only rarely, and the next "make" usually
> succeeds.

It that also --with-native-compilation?  Perhaps it's specific to that 
part of configure.ac.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> Date: Wed, 24 Aug 2022 14:04:36 +0200
> Cc: larsi@gnus.org, emacs-devel@gnu.org, luangruo@yahoo.com
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
> > It sounds like this is something macOS-specific, because for me on
> > that single system it fails only rarely, and the next "make" usually
> > succeeds.
> 
> It that also --with-native-compilation?

Yes, of course.  Otherwise the libgccjit test, which is the one that
fails, is never run by configure, not at all.

Re: Abysmal state of GTK build

[Gerd Möllmann]

On 22-08-24 14:19 , Eli Zaretskii wrote:
> Yes, of course.  Otherwise the libgccjit test, which is the one that
> fails, is never run by configure, not at all.

Thanks.  I guess that narrows it down to where brew is used in the 
libgccjit part of configure.ac.  I'll take a look.

Re: Abysmal state of GTK build

[Stefan Monnier]

> Last time I googled this, there were no plans to make autoconf
> parallel-capable.

IIUC there have been discussions but no plans, no.  Quagmire was
a proof-of-concept replacement of autoconf with something based on GNU
Make, but I don't think it went very far (and I'm no fan of GNU Make's
syntax, especially its inability to properly quote some characters).

I think the better direction is to add a Make-based step into
autoconf, which at first would only contain a single rule running the
original big-heap-of-checks then bit-by-bit split the different checks
into separate rules so they can be run in parallel.

But Someone™ needs to take this on.


        Stefan

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think the better direction is to add a Make-based step into
> autoconf, which at first would only contain a single rule running the
> original big-heap-of-checks then bit-by-bit split the different checks
> into separate rules so they can be run in parallel.

Hm...  what would this look like in practice?  Would we have a bunch of
configure.ac files -- configure-os.ac, configure-toolkit.ac, etc? 

(Which might be nice in any case, since the configure.ac file we have is
rather large.)

And then the Makefile would run the different configure bash scripts in
parallel?

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  what would this look like in practice?  Would we have a bunch of
> configure.ac files -- configure-os.ac, configure-toolkit.ac, etc? 
                                                   ^^^^^^^^^^

This is going to be a major pain in the neck to untangle from a future
configure-os.ac, so I suggest setting several weeks aside before you
attempt that.

One major problem will be the inability to find obscure systems
(i.e. Solaris 10, but with missing XkbFreeNames) on which the resulting
changes can be tested.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> One major problem will be the inability to find obscure systems
> (i.e. Solaris 10, but with missing XkbFreeNames) on which the resulting
> changes can be tested.

I don't understand your point.  This is just about splitting up the
configure tests so they can be run in parallel.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't understand your point.  This is just about splitting up the
> configure tests so they can be run in parallel.

The toolkit tests are deeply integrated with the OS tests.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> The toolkit tests are deeply integrated with the OS tests.

Oh, you're complaining about example file names for a system that
doesn't exist but that we're brainstorming.  Check.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, you're complaining about example file names for a system that
> doesn't exist but that we're brainstorming.  Check.

What?

I'm saying that it will be a significant work to split the toolkit tests
from the operating system tests.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I'm saying that it will be a significant work to split the toolkit tests
> from the operating system tests.

I have not suggested doing so.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> I'm saying that it will be a significant work to split the toolkit tests
>> from the operating system tests.
>
> I have not suggested doing so.

I guess I misunderstood you then, sorry for that.

Changing the make setup for Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If you want to discuss that, please change the Subject line
to distinguish it from the discussion of toolkits.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

change the Subject line (was: Changing the make setup for Emacs)

[andrés ramírez]

Hi.

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
[...]


    Richard> If you want to discuss that, please change the Subject line to distinguish it from the
    Richard> discussion of toolkits.

+1

And It is also part of
--8<---------------cut here---------------start------------->8---
https://www.gnu.org/philosophy/kind-communication.en.html
--8<---------------cut here---------------end--------------->8---

,---- [ It's part of the guidelines ]
| If you think the tangent is an important and pertinent issue, please
| bring it up as a separate discussion, with a Subject field to fit, and
| consider waiting for the end of the current discussion.
`----

Best Regards

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Besides, how is that related to the success of Microsoft's VS Code?

It shows exactly what I said it shows.

> The toolbar icons come from GNOME 2.x, so they are already consistent
> and (mostly) put together by designers.  Aside from the ugly cross icon,
> which really has to go.

They all have to go before we make a change in the defaults.

> Just turn off the internal border, or specify the color of the internal
> border in your X resources.

This isn't about me, it's about the default look.  It has to be fixed
before we default to no-toolkit.

>> 5) The scroll bar has to be fixed to work as modern scroll bars to, not
>> emulate the actions of an 80s Xterm.  I.e., you have to be able to drag
>> the scrool widget, and click above and below it, and have the thing
>> happen that normal users expect.
>
> I disagree, but that behavior should be made customizable.  The
> "no-toolkit" scroll bar in general is a big hack that is not portable to
> platforms other than X.

Yes, of course it should be customisable.  But the default must be to
work in the way normal users expect these days.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It shows exactly what I said it shows.

It does not.  People will use VS Code just the same, even if it used
GTK, or MS Windows, or Nextstep menu bars and popups on those respective
platforms.  AFAICT it already uses native file dialogs like all other
web browsers.

> They all have to go before we make a change in the defaults.

[...]

> This isn't about me, it's about the default look.  It has to be fixed
> before we default to no-toolkit.

So in essense, you would rather Emacs crash for our users than look
"ugly"?

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> So in essense, you would rather Emacs crash for our users than look
> "ugly"?

That's a false dichotomy.

As I've said, the crash should be fixed on our side.  You claim that
that's impossible, but I'm sure a work-around can be done (because
anything is possible).

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I've said, the crash should be fixed on our side.  You claim that
> that's impossible, but I'm sure a work-around can be done (because
> anything is possible).

It is really not fixable.  The NULL dereference is caused by GTK
mishandling an event, and we cannot withhold the event from GTK, because
then the next motion event from a newly hotplugged device will be enough
to make it crash with the same NULL dereference.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> It is really not fixable.  The NULL dereference is caused by GTK
> mishandling an event, and we cannot withhold the event from GTK, because
> then the next motion event from a newly hotplugged device will be enough
> to make it crash with the same NULL dereference.

The issue stemmed from you wanting to dis/enable the trackpad while
typing?  Then the obvious work-around is to not do that when using
XInput2 under Gtk.

It's a nice feature, but if leads to crashing in a configuration, then
it can't be used in that configuration.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The issue stemmed from you wanting to dis/enable the trackpad while
> typing?  Then the obvious work-around is to not do that when using
> XInput2 under Gtk.

That feature is provided by the operating system, not by Emacs, and was
not written by or enabled by me.  It's what the reporter of the bug did.

Re: Abysmal state of GTK build

[Gregory Heytings]

>> The issue stemmed from you wanting to dis/enable the trackpad while 
>> typing?  Then the obvious work-around is to not do that when using 
>> XInput2 under Gtk.
>
> That feature is provided by the operating system, not by Emacs, and was 
> not written by or enabled by me.  It's what the reporter of the bug did.
>

That still doesn't explain why we could not use --without-xinput2 with GTK 
builds.  Users would have the choice between a Lucid build with xinput2 
and a GTK build with xinput.

Re: Abysmal state of GTK build

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> That still doesn't explain why we could not use --without-xinput2 with
> GTK builds.  Users would have the choice between a Lucid build with
> xinput2 and a GTK build with xinput.

A GTK build with no input extension will be missing several important
features, and as a result the likes of `pixel-scroll-precision-mode'
will no longer work.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> That still doesn't explain why we could not use --without-xinput2 with
>> GTK builds.  Users would have the choice between a Lucid build with
>> xinput2 and a GTK build with xinput.
>
> A GTK build with no input extension will be missing several important
> features, and as a result the likes of `pixel-scroll-precision-mode'
> will no longer work.

But like you said, it's more important that Emacs doesn't crash.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But like you said, it's more important that Emacs doesn't crash.

Exactly, so let's default to some other build, that gives users all of
those features and doesn't crash.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> But like you said, it's more important that Emacs doesn't crash.
>
> Exactly, so let's default to some other build, that gives users all of
> those features and doesn't crash.

Again, I'm all for that, but the other builds have to be adjusted.

And the non-default builds still shouldn't crash, so disabling a
crashing feature in the Gtk build should also be done.

These two things are not in conflict with each other.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Again, I'm all for that, but the other builds have to be adjusted.

Not crashing with the same features definitely trump tool bar icons.  In
the past, those same icons were also used under the GTK build.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Not crashing with the same features definitely trump tool bar icons.  In
> the past, those same icons were also used under the GTK build.

I feel like I'm repeating myself here a lot now.  So to recap:

1) The crash under a Gtk build should be fixed -- in any case, no matter
what else we do.  If that means disabling XInput 2 under Gtk, that's fine.

2) I think we should default to not using a toolkit.  But the issues in
1-5) I delineated must be fixed first.  (This isn't a discussion -- I'm
stating a requisite.)

OK?  I'm not going to repeat these two things any more now, so if you
continue discussing these things, but I don't respond, that does not
mean that I suddenly agree with you -- but that I've given up repeating
myself.  (We've been in this situation a couple times before, so I'm
just being explicit here.)

(And did you get my off-list email, or did it go to a spam bucket
again?)

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I feel like I'm repeating myself here a lot now.  So to recap:
>
> 1) The crash under a Gtk build should be fixed -- in any case, no matter
> what else we do.  If that means disabling XInput 2 under Gtk, that's fine.

It's not fine.  Because once that happens, people will stop using the
XInput 2 build (since it will no longer be the default), and it will
simply rot like xwidgets, XEmbed, child frames, colormapped display
support.  Then, at some point, the GTK developers will delete the core
input support like they have been threatening to for a while and leave
us with no option but the now-non-working XI2 build.

Which is why XInput 2 should stay on.  GTK -- off.

> 2) I think we should default to not using a toolkit.  But the issues in
> 1-5) I delineated must be fixed first.  (This isn't a discussion -- I'm
> stating a requisite.)

Those problems are never going to be solved with our manpower, so we
might as well stop dreaming and pick something that already exists (and
for obvious reasons GTK is not an option -- that one crash is simply one
out of many.)

As I said, the only place a "no-toolkit" build exists is under X, and
even there several very old pieces of code are being used to piece
together a toolkit.  And as you've probably noticed, even that code
doesn't work very well, since most of the complicated modern toolkit
behavior is not present.  Everything from mouse-over popups in menus to
font sets and internationalized text display.

Not even Microsoft can afford to maintain their own toolkit for VS Code.
They use a web browser, which is a terrible idea that should never be
let near Emacs.

> (And did you get my off-list email, or did it go to a spam bucket
> again?)

The latter.  Here, I'm getting mail delivered two or three times from
lists.gnu.org.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Those problems are never going to be solved with our manpower, so we
> might as well stop dreaming and pick something that already exists

Stefan K has volunteered to fix the toolbar icons.  I guess the most
difficult problem would be to fix the scroll bars?

>> (And did you get my off-list email, or did it go to a spam bucket
>> again?)
>
> The latter.  Here, I'm getting mail delivered two or three times from
> lists.gnu.org.

Can you pick it out of the spam bucket or should I resend to some other
address?

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan K has volunteered to fix the toolbar icons.  I guess the most
> difficult problem would be to fix the scroll bars?

And the menu bar to display bidirectional and multilingual text, or the
menus to actually work like how people expect.  Along with implementing
file and popup dialogs (right now the latter are just implemented based
on menus.)

> Can you pick it out of the spam bucket or should I resend to some other
> address?

I don't know.  It eventually shows up.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> Can you pick it out of the spam bucket or should I resend to some other
>> address?
>
> I don't know.  It eventually shows up.

I don't know what you mean by that, either, so I'll just ask you here --
since you don't have a HiDPI system, do you want my previous laptop?
It's a Lenovo Carbon X1 (8th gen, I think) with a 4K screen?  If so, I
can send it to you.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't know what you mean by that, either, so I'll just ask you here --
> since you don't have a HiDPI system, do you want my previous laptop?

Unfortunately no, since it's rather difficult for me to receive parcels
from outside the country.  I will probably get such hardware before the
end of the year.

> It's a Lenovo Carbon X1 (8th gen, I think) with a 4K screen?  If so, I
> can send it to you.

The offer however is appreciated, thanks!

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>,  emacs-devel@gnu.org
> Date: Mon, 22 Aug 2022 21:13:55 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > I feel like I'm repeating myself here a lot now.  So to recap:
> >
> > 1) The crash under a Gtk build should be fixed -- in any case, no matter
> > what else we do.  If that means disabling XInput 2 under Gtk, that's fine.
> 
> It's not fine.  Because once that happens, people will stop using the
> XInput 2 build (since it will no longer be the default)

I don't understand: don't the non-GTK builds also support XInput2?  If
so, and if we make one of those non-GTK builds the default, people
will still have an XInput2 build, just not a GTK one.  Or what am I
missing?

> Which is why XInput 2 should stay on.  GTK -- off.

If the default, non-GTK, build supports XInput2, then why is it a
problem to have the GTK build use XInput2 only as an opt-in feature?

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand: don't the non-GTK builds also support XInput2?  If
> so, and if we make one of those non-GTK builds the default, people
> will still have an XInput2 build, just not a GTK one.  Or what am I
> missing?

I meant if the GTK build is to stay the default.

> If the default, non-GTK, build supports XInput2, then why is it a
> problem to have the GTK build use XInput2 only as an opt-in feature?

There is no problem with that, but only if GTK is turned off.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 08:47:09 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't understand: don't the non-GTK builds also support XInput2?  If
> > so, and if we make one of those non-GTK builds the default, people
> > will still have an XInput2 build, just not a GTK one.  Or what am I
> > missing?
> 
> I meant if the GTK build is to stay the default.
> 
> > If the default, non-GTK, build supports XInput2, then why is it a
> > problem to have the GTK build use XInput2 only as an opt-in feature?
> 
> There is no problem with that, but only if GTK is turned off.

Then I think we should aim for the defaults described above.

What about builds with GTK 2 -- do they have fewer problems?  Can they
support XInput2 in a reasonable way?

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Then I think we should aim for the defaults described above.
>
> What about builds with GTK 2 -- do they have fewer problems?  Can they
> support XInput2 in a reasonable way?

They support XInput 2 (and most of the other features I mentioned as
problematic on 3.x) correctly, but GTK+ 2.x is obsolete and probably
will be removed from most GNU/Linux distributions soon.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 11:05:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then I think we should aim for the defaults described above.
> >
> > What about builds with GTK 2 -- do they have fewer problems?  Can they
> > support XInput2 in a reasonable way?
> 
> They support XInput 2 (and most of the other features I mentioned as
> problematic on 3.x) correctly, but GTK+ 2.x is obsolete and probably
> will be removed from most GNU/Linux distributions soon.

That's understood, but until it is removed (which could take a few
more years, for all I know, especially in ELS distros), perhaps we
should consider preferring it to the GTK 3.x build?  If both versions
are available, that is.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > They support XInput 2 (and most of the other features I mentioned as
  > problematic on 3.x) correctly, but GTK+ 2.x is obsolete and probably
  > will be removed from most GNU/Linux distributions soon.

I think we should arrange to keep it going, so that it won't be obsolete.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Jean Louis]

Here is C++ toolkit that is fast and slick for consideration.

FLTK - Wikipedia
https://en.wikipedia.org/wiki/FLTK


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Abysmal state of GTK build

[Po Lu]

Jean Louis <bugs@gnu.support> writes:

> Here is C++ toolkit that is fast and slick for consideration.
>
> FLTK - Wikipedia
> https://en.wikipedia.org/wiki/FLTK

Just because we can use C++ in optional GUI code doesn't mean it
shouldn't be avoided if it can.

But after some investigation, I've come to the conclusion that no
toolkit will be able to replace the hand-crafted Emacs X11 support,
especially in very tricky areas such as drag-and-drop and selections.

For example, Qt doesn't respect kDNDStatusSendHereFlag in XDND
drag-and-drop messages, fails to wait for XdndStatus before sending
XdndPosition/XdndDrop, and provides no method for programs to set it on
their drop targets.  It also doesn't support the X Direct Save protocol,
which can't be implemented on top, since the special action required for
it is abstracted away and not available to programs using Emacs, or the
the Motif and OffiX drag-and-drop protocols.  All of that is tolerated
by other programs but will lead to problems over slow network
connections.

And it probably won't be possible to step through a selection converter
with Edebug, or to install our own selection converter when Qt
misencodes COMPOUND_TEXT.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 13:14:11 +0800
> 
> But after some investigation, I've come to the conclusion that no
> toolkit will be able to replace the hand-crafted Emacs X11 support,
> especially in very tricky areas such as drag-and-drop and selections.

I question the validity of such a radical conclusion.  I think it is
asking for too much, something that is not really necessary in this
case.

> For example, Qt doesn't respect kDNDStatusSendHereFlag in XDND
> drag-and-drop messages, fails to wait for XdndStatus before sending
> XdndPosition/XdndDrop, and provides no method for programs to set it on
> their drop targets.  It also doesn't support the X Direct Save protocol,
> which can't be implemented on top, since the special action required for
> it is abstracted away and not available to programs using Emacs, or the
> the Motif and OffiX drag-and-drop protocols.  All of that is tolerated
> by other programs but will lead to problems over slow network
> connections.

I think this is still better than the situation with GTK.  So yes, we
need to give up something, but if someone wants a nice toolkit
appearance and widgets that look reasonably modern (something that we
will never have in the non-toolkit build), they might just agree to
the tradeoff.  After all, no one will convince me that DND is the most
important operation in Emacs, not even that it is important.  It's a
nicety, that's all.

> And it probably won't be possible to step through a selection converter
> with Edebug, or to install our own selection converter when Qt
> misencodes COMPOUND_TEXT.

Doesn't Qt provide support for non-text selections OOTB?  If it does,
why would we need to step through the converted?

Again, we shouldn't require a perfect toolkit, we should settle for a
reasonably good one.  Because none of the alternatives is such a
perfect choice.

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Gregory Heytings <gregory@heytings.org>,  emacs-devel@gnu.org
>> Date: Tue, 23 Aug 2022 13:14:11 +0800
>> 
>> But after some investigation, I've come to the conclusion that no
>> toolkit will be able to replace the hand-crafted Emacs X11 support,
>> especially in very tricky areas such as drag-and-drop and selections.
>
> I question the validity of such a radical conclusion.  I think it is
> asking for too much, something that is not really necessary in this
> case.
>
>> For example, Qt doesn't respect kDNDStatusSendHereFlag in XDND
>> drag-and-drop messages, fails to wait for XdndStatus before sending
>> XdndPosition/XdndDrop, and provides no method for programs to set it on
>> their drop targets.  It also doesn't support the X Direct Save protocol,
>> which can't be implemented on top, since the special action required for
>> it is abstracted away and not available to programs using Emacs, or the
>> the Motif and OffiX drag-and-drop protocols.  All of that is tolerated
>> by other programs but will lead to problems over slow network
>> connections.
>
> I think this is still better than the situation with GTK.  So yes, we
> need to give up something, but if someone wants a nice toolkit
> appearance and widgets that look reasonably modern (something that we
> will never have in the non-toolkit build), they might just agree to
> the tradeoff.  After all, no one will convince me that DND is the most
> important operation in Emacs, not even that it is important.  It's a
> nicety, that's all.

Well, the point I was trying to make was that we need a toolkit where we
can use the same techniques that we already do to mix Xlib code with
toolkit code, letting the toolkit draw widgets, while allowing Emacs to
handle complicated window system behavior such as drag-and-drop.

> Doesn't Qt provide support for non-text selections OOTB?  If it does,
> why would we need to step through the converted?

COMPOUND_TEXT is an X11 specific text format that Qt doesn't support
correctly out of the box.

> Again, we shouldn't require a perfect toolkit, we should settle for a
> reasonably good one.  Because none of the alternatives is such a
> perfect choice.

Indeed, but that isn't the point I was trying to make.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 20:34:39 +0800
> 
> > I think this is still better than the situation with GTK.  So yes, we
> > need to give up something, but if someone wants a nice toolkit
> > appearance and widgets that look reasonably modern (something that we
> > will never have in the non-toolkit build), they might just agree to
> > the tradeoff.  After all, no one will convince me that DND is the most
> > important operation in Emacs, not even that it is important.  It's a
> > nicety, that's all.
> 
> Well, the point I was trying to make was that we need a toolkit where we
> can use the same techniques that we already do to mix Xlib code with
> toolkit code, letting the toolkit draw widgets, while allowing Emacs to
> handle complicated window system behavior such as drag-and-drop.

And my point is that from where I stand, the above is not an absolute,
drop-dead requirement.  Given the magnitude of the problems and the
importance of reasonably good solutions, we should be pragmatic in
this, not dogmatic.

> > Doesn't Qt provide support for non-text selections OOTB?  If it does,
> > why would we need to step through the converted?
> 
> COMPOUND_TEXT is an X11 specific text format that Qt doesn't support
> correctly out of the box.

If that's your problem, I have no problem: COMPOUND_TEXT is a niche
capability that I'm surprised people still need these days.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But after some investigation, I've come to the conclusion that no
  > toolkit will be able to replace the hand-crafted Emacs X11 support,
  > especially in very tricky areas such as drag-and-drop and selections.

This state of affairs is a big loss for the free software world.
We (in the broadest sense) ought to do something about it.

Would you like to write an article describing the drawbacks of each of
the available toolkits?  Basically, the information that has come up
in this discussion, but combined and presented in one place.

In addition to the specific technical failures, it would be good to
mention for Qt the license problem and C++ requirement.  The C++
requirement may not be a disaster, but it is a drawback.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Jean Louis]

For consideration:

List of widget toolkits - Wikipedia
https://en.wikipedia.org/wiki/List_of_widget_toolkits#Based_on_C_(including_bindings_to_other_languages)




-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Abysmal state of GTK build

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]


>
> In general, Emacs can only prevent GTK from handling certain events. 
> If it handles an event that it must handle (in this case, 
> XI_HierarchyChange) incorrectly, and that causes GTK to later 
> dereference NULL, there is nothing that Emacs can do.  Just like what 
> happens when GTK calls _exit under our nose.
>

I sent a short demo that shows how one can escape from an _exit a few 
weeks ago in bug#56967; I attach it here again.  The same kind of things 
can be done to circumvent segfaults in library functions.

[-- Attachment #2: escape-exit.tar.gz --]
[-- Type: application/gzip, Size: 743 bytes --]

Re: Abysmal state of GTK build

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> I sent a short demo that shows how one can escape from an _exit a few
> weeks ago in bug#56967; I attach it here again.  The same kind of
> things can be done to circumvent segfaults in library functions.

Sorry, but that's not a good idea.  What if someone statically links
Emacs with the C library?

And how will you escape the segfault in the static, possibly inlined
function, of the GDK X11 backend?  That's not even as reliable as
installing a signal handler to handle the SIGSEGV, which is once again a
very bad idea.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> I sent a short demo that shows how one can escape from an _exit a few
>> weeks ago in bug#56967; I attach it here again.  The same kind of
>> things can be done to circumvent segfaults in library functions.

Cool!

> Sorry, but that's not a good idea.  What if someone statically links
> Emacs with the C library?

That's not the default configuration, and if somebody is wild enough to
do that, then that's not our problem.

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That's not the default configuration, and if somebody is wild enough to
> do that, then that's not our problem.

And it still doesn't show how to work around the segfault in an
internal, possibly inlined, static GTK function.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> And it still doesn't show how to work around the segfault in an
> internal, possibly inlined, static GTK function.

Well, segfault handling is ambitious, but _exit handling is what we're
really looking for (to fix the emacsclient multi-display stuff), right?

Re: Abysmal state of GTK build

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, segfault handling is ambitious, but _exit handling is what we're
> really looking for (to fix the emacsclient multi-display stuff), right?

Oh, that doesn't fix the emacsclient multi-display stuff at all -- GTK
will still crash immediately afterwards.  We want the _exit handling to
be able to auto-save users work on the PGTK build.

Re: Abysmal state of GTK build

[Thomas Fitzsimmons]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> I sent a short demo that shows how one can escape from an _exit a few
>>> weeks ago in bug#56967; I attach it here again.  The same kind of
>>> things can be done to circumvent segfaults in library functions.
>
> Cool!
>
>> Sorry, but that's not a good idea.  What if someone statically links
>> Emacs with the C library?
>
> That's not the default configuration, and if somebody is wild enough to
> do that, then that's not our problem.

Since we're talking about extreme ideas, how about this: create a light
fork of GTK that contains a bunch of bug fixes that make Emacs happy,
pull it in as a submodule, build it as part of Emacs's
--with-x-toolkit=gtk build, then have the Emacs binary load the forked
GTK library at runtime.  (Or to borrow a term from other language
communities, Emacs could "vendor" GTK.)

Thomas

Re: Abysmal state of GTK build

[Po Lu]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Since we're talking about extreme ideas, how about this: create a light
> fork of GTK that contains a bunch of bug fixes that make Emacs happy,
> pull it in as a submodule, build it as part of Emacs's
> --with-x-toolkit=gtk build, then have the Emacs binary load the forked
> GTK library at runtime.  (Or to borrow a term from other language
> communities, Emacs could "vendor" GTK.)

GTK's copyright is not assigned to the FSF.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > GTK's copyright is not assigned to the FSF.

That is not an obstacle, as long as we keep that module separate
and we clearly show that it is not part of GNU Emacs.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Dmitry Gutov]

[-- Attachment #1: Type: text/html, Size: 662 bytes --]

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In general, Emacs can only prevent GTK from handling certain events.  If
  > it handles an event that it must handle (in this case,
  > XI_HierarchyChange) incorrectly, and that causes GTK to later
  > dereference NULL, there is nothing that Emacs can do.  Just like what
  > happens when GTK calls _exit under our nose.

With so many messages on this topic, I can't see whether someone
already tried reporting these bugs to GTK developers and saying we find
them very painful.  Has that been tried?

Have we tried patching GTK to add workarounds -- for instance,
defining an "exit function" hook to call instead of `_exit'?
We could distribute such patches, and they might accept the patches.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> With so many messages on this topic, I can't see whether someone
> already tried reporting these bugs to GTK developers and saying we find
> them very painful.  Has that been tried?

Yes.  In most cases they do not want to accept the resulting changes.
In fact, they even want to delete support for X11 in its entirety.

> Have we tried patching GTK to add workarounds -- for instance,
> defining an "exit function" hook to call instead of `_exit'?
> We could distribute such patches, and they might accept the patches.

They insist that it is unsafe to call anything except for _exit, because
it is not safe to save files after the display server goes down.

It's nonsense, and it's coming from the same group of people who call
users "clowns" and "the internet peanut gallery".

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Have we tried patching GTK to add workarounds -- for instance,
  > > defining an "exit function" hook to call instead of `_exit'?
  > > We could distribute such patches, and they might accept the patches.

  > They insist that it is unsafe to call anything except for _exit, because
  > it is not safe to save files after the display server goes down.

There are various ways users can make such modifications.
We can add those to the list of possible options to compare.
This is for GTK 3, right?

One pwrtinent question is, how bad would the problems of GTK 3 be if
we imagine a few of them have been fided this way?  Would they be bad
enough that we would want to reject GTK 3 over them anyway?

There is a modified version of GNOME 2, which I suppose includes GTK
2.  It is called Maté.  (The accent on "ë is incorrect Spanish, but it
is correct English.)  It is no longer maintained, but it is probably a
better starting point than GNOME 2 itself.  I use it, because it is
included in Trisquel.  I presume it contains a version of GTK 2.

If newer versions of GTK are lousy, and the other options also have
bad problems, maybe this is the best.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> There are various ways users can make such modifications.
> We can add those to the list of possible options to compare.
> This is for GTK 3, right?
>
> One pwrtinent question is, how bad would the problems of GTK 3 be if
> we imagine a few of them have been fided this way?  Would they be bad
> enough that we would want to reject GTK 3 over them anyway?

Yeah.  It would be a lot of work to do that.

> There is a modified version of GNOME 2, which I suppose includes GTK
> 2.  It is called Maté.  (The accent on "ë is incorrect Spanish, but it
> is correct English.)  It is no longer maintained, but it is probably a
> better starting point than GNOME 2 itself.  I use it, because it is
> included in Trisquel.  I presume it contains a version of GTK 2.

Some parts of Mate have apparently been ported to GTK 3.  I'm not sure.

> If newer versions of GTK are lousy, and the other options also have
> bad problems, maybe this is the best.

I guess we could take up maintenance of GTK 2.  But it would still be a
lot of work.

Re: Abysmal state of GTK build

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

On Wed, Aug 24, 2022 at 12:20:26PM +0800, Po Lu wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> > There are various ways users can make such modifications.
> > We can add those to the list of possible options to compare.
> > This is for GTK 3, right?
> >
> > One pwrtinent question is, how bad would the problems of GTK 3 be if
> > we imagine a few of them have been fided this way?  Would they be bad
> > enough that we would want to reject GTK 3 over them anyway?
> 
> Yeah.  It would be a lot of work to do that.
> 
> > There is a modified version of GNOME 2, which I suppose includes GTK
> > 2.  It is called Maté.  (The accent on "ë is incorrect Spanish, but it
> > is correct English.)  It is no longer maintained, but it is probably a
> > better starting point than GNOME 2 itself.  I use it, because it is
> > included in Trisquel.  I presume it contains a version of GTK 2.

Hm. I only know of MATE (spelled in capitals) [1] [2], named after yerba
mate (which doesn't have an accent).

This one tries to be like Gnome 2 (I know a few users who were glad to
move to MATE after Gnome 3 came out).

Mate switched to Gtk3 a while ago, though (the current Debian dependency
of Marco, MATE's window manager, for example, is on Gtk3).

> Some parts of Mate have apparently been ported to GTK 3.  I'm not sure.

Yes, see above.

> > If newer versions of GTK are lousy, and the other options also have
> > bad problems, maybe this is the best.
> 
> I guess we could take up maintenance of GTK 2.  But it would still be a
> lot of work.

Indeed. Possibly comparable to making Lucid "nice". Don't know.

Cheers

[1] https://en.wikipedia.org/wiki/MATE_(software)
[2] https://git.mate-desktop.org/

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > If newer versions of GTK are lousy, and the other options also have
  > > bad problems, maybe this is the best.

  > I guess we could take up maintenance of GTK 2.  But it would still be a
  > lot of work.

This is why I suggest that we systematically investigate the amount of
work in each of the alternative ways to get an adequate graphical
display library for Emacs, in an adequate desktop.  Then we can
compare them and see which one looks like the least work in total.

Then we'll simply have to get the job done.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Have we tried patching GTK to add workarounds -- for instance,
>   > > defining an "exit function" hook to call instead of `_exit'?
>   > > We could distribute such patches, and they might accept the patches.
>
>   > They insist that it is unsafe to call anything except for _exit, because
>   > it is not safe to save files after the display server goes down.
>
> There are various ways users can make such modifications.
> We can add those to the list of possible options to compare.
> This is for GTK 3, right?
>
> One pwrtinent question is, how bad would the problems of GTK 3 be if
> we imagine a few of them have been fided this way?  Would they be bad
> enough that we would want to reject GTK 3 over them anyway?
>
> There is a modified version of GNOME 2, which I suppose includes GTK
> 2.  It is called Maté.  (The accent on "ë is incorrect Spanish, but it
> is correct English.)  It is no longer maintained, but it is probably a
> better starting point than GNOME 2 itself.  I use it, because it is
> included in Trisquel.  I presume it contains a version of GTK 2.
>
> If newer versions of GTK are lousy, and the other options also have
> bad problems, maybe this is the best.

I think mate is still maintained. Both Ubuntu and Fedora have current
versions of their distribution which is based on it. I think cinnamon is
also based on GTK2?

Re: Abysmal state of GTK build

[tomas]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Wed, Aug 24, 2022 at 02:25:14PM +1000, Tim Cross wrote:

[...]

> I think mate is still maintained. Both Ubuntu and Fedora have current
> versions of their distribution which is based on it. I think cinnamon is
> also based on GTK2?

It sure is. Stable release is one year old. Latest patches are weeks
old. It's alive.

But it moved to Gtk3, it seems.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Abysmal state of GTK build

[Tim Cross]

<tomas@tuxteam.de> writes:

> [[PGP Signed Part:Undecided]]
> On Wed, Aug 24, 2022 at 02:25:14PM +1000, Tim Cross wrote:
>
> [...]
>
>> I think mate is still maintained. Both Ubuntu and Fedora have current
>> versions of their distribution which is based on it. I think cinnamon is
>> also based on GTK2?
>
> It sure is. Stable release is one year old. Latest patches are weeks
> old. It's alive.
>
> But it moved to Gtk3, it seems.
>

OK, good to know. I switched away from matge when I moved to fedora,
selecting the xfce spin instead as I realise, I just want something
simple and light. 

Re: Abysmal state of GTK build

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> I think mate is still maintained. Both Ubuntu and Fedora have current
> versions of their distribution which is based on it. I think cinnamon is
> also based on GTK2?

Cinnamon is a fork of GNOME 3, based on GTK 3.  I looked it up and Mate
has been ported to GTK 3 as well.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think mate is still maintained.

Can you find out who some of the maintainers are, and tell me?

Are you talking about the version of Mate that works with GTK 2?
Or some newer version that requires GTK 3?

Might it be that Mate for GTK 3 is maintained but the Mate
I use, for GTK 2, is not?

We don't want Emacs to use GTK 3, but is it a problem
if the Mate programs use GTK 3 while Emacs uses GTK 2?

Is using Mate running with GTK 3 tantamount to using GNOME 3?
Or is it still like  GNOME 2?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I think mate is still maintained.
>
> Can you find out who some of the maintainers are, and tell me?
>
> Are you talking about the version of Mate that works with GTK 2?
> Or some newer version that requires GTK 3?
>
> Might it be that Mate for GTK 3 is maintained but the Mate
> I use, for GTK 2, is not?
>
> We don't want Emacs to use GTK 3, but is it a problem
> if the Mate programs use GTK 3 while Emacs uses GTK 2?
>
> Is using Mate running with GTK 3 tantamount to using GNOME 3?
> Or is it still like  GNOME 2?

Apparently it is still maintained, but it has now moved to GTK3. Both
Ubutnu and Fedora have versions of their distribution based on the
current mate desktop.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Is using Mate running with GTK 3 tantamount to using GNOME 3?
  > > Or is it still like  GNOME 2?

  > Apparently it is still maintained, but it has now moved to GTK3. Both
  > Ubutnu and Fedora have versions of their distribution based on the
  > current mate desktop.

I still have the questions:
Is using Mate running with GTK 3 tantamount to using GNOME 3?
Or is it still like  GNOME 2?

Another question: do programs that use GTK 2 work well with Mate
if Mate uses GTK 3?

Another question: do Mate programs ever get screwed by surprise calls
to _exit inside GTK 3?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Is using Mate running with GTK 3 tantamount to using GNOME 3?
> Or is it still like  GNOME 2?

It is still like GNOME 2.

> Another question: do programs that use GTK 2 work well with Mate
> if Mate uses GTK 3?

Yes, as long as GTK+ 2.x is installed.  Those programs generally work
well everywhere.

> Another question: do Mate programs ever get screwed by surprise calls
> to _exit inside GTK 3?

Yes, they do.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Is using Mate running with GTK 3 tantamount to using GNOME 3?
  > > Or is it still like  GNOME 2?

  > It is still like GNOME 2.

THat's good.  I think that Mate is still a solution to consider.

  > > Another question: do programs that use GTK 2 work well with Mate
  > > if Mate uses GTK 3?

  > Yes, as long as GTK+ 2.x is installed.  Those programs generally work
  > well everywhere.

  > > Another question: do Mate programs ever get screwed by surprise calls
  > > to _exit inside GTK 3?

  > Yes, they do.

Maybe the Mate developers would be interested in the idea of making
a modified version of GTK 3 to fix this.

It might be easy to do by compiling GTK 3 with a macro definition
to define _exit to call some function we would define.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Is using Mate running with GTK 3 tantamount to using GNOME 3?
>   > > Or is it still like  GNOME 2?
>
>   > Apparently it is still maintained, but it has now moved to GTK3. Both
>   > Ubutnu and Fedora have versions of their distribution based on the
>   > current mate desktop.
>
> I still have the questions:
> Is using Mate running with GTK 3 tantamount to using GNOME 3?
> Or is it still like  GNOME 2?
>

I don't understand this question. Gnome is a desktop environment, Mate
is an alternative desktop environment. They both use GTK as a GUI
toolkit library. If it at all helps, I had not noticed any difference in
Mate from when it was using GTK2 to when it was using GTK3 (Just as I
had noticed no difference in Emacs when it started using GTK3 instead of
GTK2). 


> Another question: do programs that use GTK 2 work well with Mate
> if Mate uses GTK 3?
>

I doubt it at all matters. The desktop environment (DE) doesn't at all
care about what the individual programs are using as their GUI toolkitg
(it doesn't even know). For example, I don't run Gnome, Mate or any
other GTK based DE or window manager and I will still be vulnerable to
the GTK3 issues (although apparently I've been lucky and they have never
occurred for me). 

Re: Abysmal state of GTK build

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> We need somebody, preferably a designer, to put together a set of
> consistent (and pretty) toolbar icons.

I'll try to get my act together and push the icon stuff I've been
working on.  It solves this using scalable svg icons.

Re: Abysmal state of GTK build

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I'll try to get my act together and push the icon stuff I've been
> working on.  It solves this using scalable svg icons.

Great!

Re: Abysmal state of GTK build

[Visuwesh]

[ஞாயிறு ஆகஸ்ட் 21, 2022] Lars Ingebrigtsen wrote:

> "Since this issue found its way on Phoronix and reddit I'm going to
> temporarily lock it, to ensure a modicum of decency and avoid lowering
> the bar of the comments."
>
> Anyway, I'm all in favour of defaulting to a no-toolkit build (across
> all systems -- the astounding success of VS Code has show that having a
> consistent look across systems is much more important than respecting
> the look of the OS).
>
> But we have to fix the no-toolkit look before we can contemplate that.
>
> [5 points]

BTW, I think another item worthy of note is that Lucid menus cannot
display multilingual text.  See the outline "** Make the Lucid menu
widget display multilingual text" in etc/TODO.

Re: Abysmal state of GTK build

[Po Lu]

Visuwesh <visuweshm@gmail.com> writes:

> BTW, I think another item worthy of note is that Lucid menus cannot
> display multilingual text.  See the outline "** Make the Lucid menu
> widget display multilingual text" in etc/TODO.

It already does if you don't build with Xft or Cairo.

Re: Abysmal state of GTK build

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > BTW, I think another item worthy of note is that Lucid menus cannot
  > display multilingual text.  See the outline "** Make the Lucid menu
  > widget display multilingual text" in etc/TODO.

Perhaps the question we should be studying is, "Which is the easiest
path to making Emacs handle graphical display well?"

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Abysmal state of GTK build

[Visuwesh]

[திங்கள் ஆகஸ்ட் 22, 2022] Richard Stallman wrote:

>
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > BTW, I think another item worthy of note is that Lucid menus cannot
>   > display multilingual text.  See the outline "** Make the Lucid menu
>   > widget display multilingual text" in etc/TODO.
>
> Perhaps the question we should be studying is, "Which is the easiest
> path to making Emacs handle graphical display well?"

Apart from bug#54646 and this menu issue, I haven't had any graphical
issues with the Lucid build.

Re: Abysmal state of GTK build

[Rudolf Adamkovič]

Richard Stallman <rms@gnu.org> writes:

> Perhaps the question we should be studying is, "Which is the easiest
> path to making Emacs handle graphical display well?"

+1 We should look at the big picture and keep the discussion going until
we know where to go long-term.  Further, why not look at the other free
projects that have solved the problem already?

For example, I keep hearing about how Blender does a fantastic job with
their UI, which is multi-platform and yet highly praised.  The UI caters
perfectly to the program and to the people who use it.  That aligns with
the "Emacs way" more than fighting GUI frameworks that keep changing
with UX fashion like Gnome and GTK do, in my opinion.

The Blender website says:

> All the components that together make Blender are compatible under the
> newer GNU GPL Version 3. That is also the license to use for any
> distribution of Blender binaries.

Could we learn anything from Blender?  Obviously, Emacs has different
requirements, such as a more advanced "text view" component, but what
about the rest?

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't.  That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Abysmal state of GTK build

[Po Lu]

Rudolf Adamkovič <salutis@me.com> writes:

> +1 We should look at the big picture and keep the discussion going until
> we know where to go long-term.  Further, why not look at the other free
> projects that have solved the problem already?
>
> For example, I keep hearing about how Blender does a fantastic job with
> their UI, which is multi-platform and yet highly praised.  The UI caters
> perfectly to the program and to the people who use it.  That aligns with
> the "Emacs way" more than fighting GUI frameworks that keep changing
> with UX fashion like Gnome and GTK do, in my opinion.

[...]

> Could we learn anything from Blender?  Obviously, Emacs has different
> requirements, such as a more advanced "text view" component, but what
> about the rest?

I note that Blender has much more development momentum than Emacs, and
was one of the programs I tested while working on the drag-and-drop
support.

It has several big problems there, including only supporting version 3
of the XDND protocol (which is obsolete and most noticeably does not
work with other programs written with GTK+, both 2.x and 3.x), not
deleting XdndTypeList after the drag-and-drop operation completes, and
not deleting the property given in a SelectionNotify event after reading
it.

It also doesn't support frame resize synchronization, so resizing a
Blender window will make its contents lag behind the resize.  Compare
that to Emacs 29, under a compositing manager such as GNOME Shell.

Blender's menus are also a sore spot.  They do not grab the mouse or
workably extend outside the toplevel window boundaries, which makes
displaying long menus (think Help -> Describe -> Describe Language
Environment) very annoying.

The other fundamental difference between us and Blender is that Blender
is 3D animation software, and thus can afford all of these problems,
since graphics professionals will be running it fullscreen, not
alongside other programs on a desktop.  We can not, especially not when
every other text editor that does use a toolkit does all of that
correctly.

So, if a project as large as Blender cannot get it right, how is it
practical for us to do so?