Re: Abysmal state of GTK build

Re: Abysmal state of GTK build

[Payas Relekar]

Po Lu <luangruo@yahoo.com> writes:

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

How much of an issue will this be on Wayland systems? Considering GTK4
will probably drop X11 support, and Fedora, Debian and Ubuntu (likely
covering vast majority of Linux desktop) are Wayland default, how much
of a critical dependence do we have on custom X11 support, and how much
can we afford to rely on Qt to not have these issues on Wayland?

Thanks,
Payas

--

Re: Abysmal state of GTK build

[Po Lu]

Payas Relekar <relekarpayas@gmail.com> writes:

> How much of an issue will this be on Wayland systems? Considering GTK4
                                                                    ^^^^
That will hopefully be GTK 5.

> will probably drop X11 support, and Fedora, Debian and Ubuntu (likely
> covering vast majority of Linux desktop) are Wayland default, how much
> of a critical dependence do we have on custom X11 support, and how much
> can we afford to rely on Qt to not have these issues on Wayland?

It will not affect Wayland at all, since the Wayland drag-and-drop API
is too limited to allow Emacs to implement drag-and-drop properly there.

Most importantly, there is no way to cancel drag-and-drop after it
begins (think C-g), or to receive a notification when the pointer
reenters the frame where it originated after leaving.

X will probably remain the primary window server for the next decade or
so.  Anyone who doesn't want to use one of the several Wayland-ready
desktop environments on supported hardware will have to use X, even if
Wayland is the default on most distros.

Re: Abysmal state of GTK build

[Payas Relekar]

Po Lu <luangruo@yahoo.com> writes:

> Payas Relekar <relekarpayas@gmail.com> writes:
>
>> How much of an issue will this be on Wayland systems? Considering GTK4
>                                                                     ^^^^
> That will hopefully be GTK 5.

Indeed, I checked and you are correct. That puts X11 demise on 10+ year
timeline.

>> will probably drop X11 support, and Fedora, Debian and Ubuntu (likely
>> covering vast majority of Linux desktop) are Wayland default, how much
>> of a critical dependence do we have on custom X11 support, and how much
>> can we afford to rely on Qt to not have these issues on Wayland?
>
> It will not affect Wayland at all, since the Wayland drag-and-drop API
> is too limited to allow Emacs to implement drag-and-drop properly there.
>
> Most importantly, there is no way to cancel drag-and-drop after it
> begins (think C-g), or to receive a notification when the pointer
> reenters the frame where it originated after leaving.

That is unfortunate. Considering HiDPI + mixed DPI support is
non-existent in X11, I was really hoping Wayland feature bulimia to be
solved/on-way-to-be-solved problem by now.

> X will probably remain the primary window server for the next decade or
> so.  Anyone who doesn't want to use one of the several Wayland-ready
> desktop environments on supported hardware will have to use X, even if
> Wayland is the default on most distros.

That is fair. From what I understand Wayland support on non-Linux
systems is still imperfect at best so X11 support is here to stay. But,
can we have it as non-default and get away with it for the most part?
Considering drag-and-drop situation you mentioned above I am not
expecting rainbows, but is it something we can try for?

Apologies for simple (and possibly stupid) questions, but GTK situation has more thorns than
I previously thought. Considering WSL2 will have more people using Emacs
via Wayland/Pgtk making defaults more important.

Thanks,
Payas

--

Re: Abysmal state of GTK build

[Po Lu]

Payas Relekar <relekarpayas@gmail.com> writes:

> Indeed, I checked and you are correct. That puts X11 demise on 10+ year
> timeline.

What makes you think the GTK developers will be able to dictate what
people will use?

Remember that if the world revolved around their decisions, we would all
be clowns occupying a peanut gallery.

> That is unfortunate. Considering HiDPI + mixed DPI support is
> non-existent in X11, I was really hoping Wayland feature bulimia to be
> solved/on-way-to-be-solved problem by now.

Why do you think that's so?  On X, the X server says nothing about the
scale of a window, screen, or the part of a screen taken by a monitor.
A program can simply rescale itself as it moves across different
outputs.

I think the reason people think HiDPI support doesn't work on X is that
it doesn't work in Xwayland, which is strictly a problem with that, and
is not seen on bare-metal X.

> That is fair. From what I understand Wayland support on non-Linux
> systems is still imperfect at best so X11 support is here to
> stay. But, can we have it as non-default and get away with it for the
> most part?

No.  AFAIK it was recently discovered that less than 10% of Firefox
users on non-macOS Unix systems were using Wayland or Xwayland.

> Apologies for simple (and possibly stupid) questions, but GTK
> situation has more thorns than I previously thought. Considering WSL2
> will have more people using Emacs via Wayland/Pgtk making defaults
> more important.

I don't think supporting the PGTK build on MS Windows is a good idea at
all.

Re: Abysmal state of GTK build

[Stefan Monnier]

> A program can simply rescale itself as it moves across different
> outputs.

There's always the issue of windows (frames) spanning several monitors
with different DPI.


        Stefan

Re: Abysmal state of GTK build

[Po Lu]

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

> There's always the issue of windows (frames) spanning several monitors
> with different DPI.

That isn't handled on Wayland either.

Re: Abysmal state of GTK build

[Stefan Monnier]

Po Lu [2022-08-24 09:16:25] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> There's always the issue of windows (frames) spanning several monitors
>> with different DPI.
> That isn't handled on Wayland either.

Bummer!


        Stefan

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Gregory Heytings
>  <gregory@heytings.org>,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 15:17:42 +0800
> 
> It will not affect Wayland at all, since the Wayland drag-and-drop API
> is too limited to allow Emacs to implement drag-and-drop properly there.
> 
> Most importantly, there is no way to cancel drag-and-drop after it
> begins (think C-g), or to receive a notification when the pointer
> reenters the frame where it originated after leaving.

Why is this such a grave problem?  E.g., to cancel drag-and-drop, the
user can drop it onto some place where dropping is a no-op, like some
window that doesn't accept drops or sometimes at the source from which
the stuff was dragged.  I never had any problems with this.

Maybe we are again asking too much from the GUI environment, and too
easily reject environments that are not 110% perfect?  If so, it makes
little sense to do that with Emacs, whose GUI aspects are secondary.

> X will probably remain the primary window server for the next decade or
> so.

It is IMNSHO bad policy for a serious project that intends to remain
alive for many years to put all of its eggs in a single basket.  We
should instead actively seek and try using alternative GUI
environments, and we shouldn't reject them just because they are not
perfect.

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Why is this such a grave problem?  E.g., to cancel drag-and-drop, the
> user can drop it onto some place where dropping is a no-op, like some
> window that doesn't accept drops or sometimes at the source from which
> the stuff was dragged.  I never had any problems with this.

[...]

> Maybe we are again asking too much from the GUI environment, and too
> easily reject environments that are not 110% perfect?  If so, it makes
> little sense to do that with Emacs, whose GUI aspects are secondary.

mouse-drag-and-drop-region cancels the drag and drop operation once the
mouse pointer moves back into a frame that was created by the current
Emacs session, so that more detailed mouse tracking can be used.

Without that, mouse-drag-and-drop-region is noticably degraded.

> It is IMNSHO bad policy for a serious project that intends to remain
> alive for many years to put all of its eggs in a single basket.  We
> should instead actively seek and try using alternative GUI
> environments, and we shouldn't reject them just because they are not
> perfect.

We aren't rejecting alternative GUI environments (in fact we are almost
certainly the only program supporting as many as we do), just not making
them the default.  Not when over 90% of Firefox users (which covers the
GNU/Linux demographic quite well) are still using X Windows.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: relekarpayas@gmail.com,  larsi@gnus.org,  gregory@heytings.org,
>   emacs-devel@gnu.org
> Date: Tue, 23 Aug 2022 20:29:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is this such a grave problem?  E.g., to cancel drag-and-drop, the
> > user can drop it onto some place where dropping is a no-op, like some
> > window that doesn't accept drops or sometimes at the source from which
> > the stuff was dragged.  I never had any problems with this.
> 
> [...]
> 
> > Maybe we are again asking too much from the GUI environment, and too
> > easily reject environments that are not 110% perfect?  If so, it makes
> > little sense to do that with Emacs, whose GUI aspects are secondary.
> 
> mouse-drag-and-drop-region cancels the drag and drop operation once the
> mouse pointer moves back into a frame that was created by the current
> Emacs session, so that more detailed mouse tracking can be used.
> 
> Without that, mouse-drag-and-drop-region is noticably degraded.

I disagree.  As I said, the user can drop it in some place where
dropping is a no-op.

And let's not forget that drag-and-drop operation mostly ends in a
drop, not in a cancel.  Canceling should be much rarer than dropping.

> > It is IMNSHO bad policy for a serious project that intends to remain
> > alive for many years to put all of its eggs in a single basket.  We
> > should instead actively seek and try using alternative GUI
> > environments, and we shouldn't reject them just because they are not
> > perfect.
> 
> We aren't rejecting alternative GUI environments (in fact we are almost
> certainly the only program supporting as many as we do), just not making
> them the default.

I'm not talking about the ones we already support, I'm talking about
the future policies of trying to use alternatives to X.  It was a
response to what you said:

> X will probably remain the primary window server for the next decade or
> so.

I'm saying that we shouldn't stop looking for reasonably good GUI
environments because we are complacent with X.

Re: Abysmal state of GTK build

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I disagree.  As I said, the user can drop it in some place where
> dropping is a no-op.
>
> And let's not forget that drag-and-drop operation mostly ends in a
> drop, not in a cancel.  Canceling should be much rarer than dropping.

Sure, if you think that's okay I will continue working on the PGTK
drag-and-drop support.

>> X will probably remain the primary window server for the next decade or
>> so.
>
> I'm saying that we shouldn't stop looking for reasonably good GUI
> environments because we are complacent with X.

I guess you misunderstood what I said.  I just said alternatives to X
shouldn't be made the default, since almost everyone will be using X for
the forseeable future.

Re: Abysmal state of GTK build

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> I guess you misunderstood what I said.  I just said alternatives to X
> shouldn't be made the default, since almost everyone will be using X for
> the forseeable future.

The 90% X Firefox user share you mentioned several times was a statistic
of dubious relevance when it came out 6 months ago and is pretty much
irrelevant now. The Mozilla Telemetry guys said at the time that it is
not truly representative, for several reasons. And, more importantly,
Wayland adoption is gaining momentum, with major distros (such as
Ubuntu) defaulting to it and KDE joining Gnome as a stable Wayland-based
desktop environment.

I'll say that by 2025 Wayland will be more popular than X by a wide
margin, and then X will have a hard time with basic maintenance by lack
of manpower (some insiders say that it already suffers from that.)

This doesn't mean much for Emacs on the short and medium term. Emacs
works on XWayland, and XWayland is improving so applications running on
it doesn't suffer from a degraded user experience compared to native
Wayland ones, apart from the constraints related to being based on X.

Another claim you made several times is that distros will stop providing
GTK2 packages soon. This is hard to believe, since other major
applications (such as GIMP, as you said) also use GTK2 and distros still
provide packages for libraries way more ancient and obscure than GTK2.

Finally, it seems to me that your experience with some GTK developers is
influencing your technical discussion on this thread.

Re: Abysmal state of GTK build

[Visuwesh]

[செவ்வாய் ஆகஸ்ட் 23, 2022] Óscar Fuentes wrote:

> Another claim you made several times is that distros will stop providing
> GTK2 packages soon. This is hard to believe, since other major
> applications (such as GIMP, as you said) also use GTK2 and distros still
> provide packages for libraries way more ancient and obscure than GTK2.

IIRC, GIMP's development version has migrated to Gtk3.
See https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 23 Aug 2022 17:13:58 +0200
> 
> Finally, it seems to me that your experience with some GTK developers is
> influencing your technical discussion on this thread.

Why shouldn't it?  The attitude of the GTK developers is certainly
relevant for our decisions related to GTK issues.

Re: Abysmal state of GTK build

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Finally, it seems to me that your experience with some GTK developers is
>> influencing your technical discussion on this thread.
>
> Why shouldn't it?  The attitude of the GTK developers is certainly
> relevant for our decisions related to GTK issues.

... suppossing that the depiction of those developers is accurate, fair
and representative of the community, not picking one or two individuals
interacting with one other individual at certain time.

Besides, people come and go.

Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 23 Aug 2022 18:41:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Finally, it seems to me that your experience with some GTK developers is
> >> influencing your technical discussion on this thread.
> >
> > Why shouldn't it?  The attitude of the GTK developers is certainly
> > relevant for our decisions related to GTK issues.
> 
> ... suppossing that the depiction of those developers is accurate, fair
> and representative of the community, not picking one or two individuals
> interacting with one other individual at certain time.

They were actually quoted here on several occasions.  Make your own
conclusions from what they say; I did.

Re: Abysmal state of GTK build

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Finally, it seems to me that your experience with some GTK
>> >> developers is influencing your technical discussion on this
>> >> thread.
>> >
>> > Why shouldn't it?  The attitude of the GTK developers is certainly
>> > relevant for our decisions related to GTK issues.
>> 
>> ... suppossing that the depiction of those developers is accurate, fair
>> and representative of the community, not picking one or two individuals
>> interacting with one other individual at certain time.
>
> They were actually quoted here on several occasions.  Make your own
> conclusions from what they say; I did.

What I see on that Merge Request is an occasional contributor adding
code related to an internal, debug-related environment variable to avoid
its abuse and then making an insulting reference to the people who are
advicing others to incur on said abuse. Then another occasional
contributor comes to close the comments (good) with a blunt phrase
(bad).

Implying that that episode illustrates the general attitude of that
community and that it is relevant to how Emacs should decide its
relation to the products of such community is... unfair, to say it
politelly.

Re: Abysmal state of GTK build

[Po Lu]

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

> What I see on that Merge Request is an occasional contributor adding
> code related to an internal, debug-related environment variable to avoid
> its abuse and then making an insulting reference to the people who are
> advicing others to incur on said abuse. Then another occasional
> contributor comes to close the comments (good) with a blunt phrase
> (bad).

What abuse? And the change did not add code, it removed code to prevent
users from customizing their own systems in a way that the GTK
developers do not want.  Even though it causes no problems, no bug
reports, and in general no trouble at all for anyone, especially for
someone who did not even write the GTK native dialog code.

Stop making excuses for the blatant disrespect for users and developers
carried by the GTK developers.  Here's what the AUTHORS file says:

The current team (GTK 3 and 4)
------------------------------

Jonas Ådahl       <jadahl@gmail.com>
Tim Bäder         <mail@baedert.org>
Emmanuele Bassi   <ebassi@gnome.org>
Chun-wei Fan      <fanchunwei@src.gnome.org>
Matthias Clasen   <mclasen@redhat.com>
Carlos Garnacho   <mrgarnacho@gmail.com>
Alexander Larsson <alexl@redhat.com>
Benjamin Otte     <otte@gnome.org>

Evidently, Benjamin Otte is not just an "occasional contributor".

> Implying that that episode illustrates the general attitude of that
> community and that it is relevant to how Emacs should decide its
> relation to the products of such community is... unfair, to say it
> politelly.

Okay, then how about the many MANY times we went to them about the
display disconnect problem, and were very impolitely rebuffed, with our
use case(s) dismissed?

Or recently:

  https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg00687.html

Where they made the ridiculous statement that it is unsafe for Emacs to
auto-save data in Emacs core if the Wayland compositor shuts down.

Re: Abysmal state of GTK build

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> What I see on that Merge Request is an occasional contributor adding
>> code related to an internal, debug-related environment variable to avoid
>> its abuse and then making an insulting reference to the people who are
>> advicing others to incur on said abuse. Then another occasional
>> contributor comes to close the comments (good) with a blunt phrase
>> (bad).
>
> What abuse? And the change did not add code, it removed code to prevent
> users from customizing their own systems in a way that the GTK
> developers do not want.  Even though it causes no problems, no bug
> reports, and in general no trouble at all for anyone, especially for
> someone who did not even write the GTK native dialog code.

Suppose you discover that some people are writing customization recipes
on a popular Wiki page that make use of internal Emacs code for whatever
purpose, and you know that once you change that code people will come to
complain about you for breaking their setups.

Of course, that's no excuse for calling names on anyone, but otherwise
what he did is not unreasonable.

> Stop making excuses for the blatant disrespect for users and developers
> carried by the GTK developers.  Here's what the AUTHORS file says:
>
> The current team (GTK 3 and 4)
> ------------------------------
>
> Jonas Ådahl       <jadahl@gmail.com>
> Tim Bäder         <mail@baedert.org>
> Emmanuele Bassi   <ebassi@gnome.org>
> Chun-wei Fan      <fanchunwei@src.gnome.org>
> Matthias Clasen   <mclasen@redhat.com>
> Carlos Garnacho   <mrgarnacho@gmail.com>
> Alexander Larsson <alexl@redhat.com>
> Benjamin Otte     <otte@gnome.org>
>
> Evidently, Benjamin Otte is not just an "occasional contributor".

Well, I said that he is an occasional contributor after looking at his
activity map, which is not very colorful.

OTOH, he belonging to the official team may explain why he was not
censured. That doesn't mean that other team members sympathize with his
action.

>> Implying that that episode illustrates the general attitude of that
>> community and that it is relevant to how Emacs should decide its
>> relation to the products of such community is... unfair, to say it
>> politelly.
>
> Okay, then how about the many MANY times we went to them about the
> display disconnect problem, and were very impolitely rebuffed, with our
> use case(s) dismissed?

There is a bitter disagreement there, for sure. But I've experienced
worse dealing with KDE/Qt maintainers and I still am a happy KDE user.
That is, if you think that by switching to Qt you will deal with more
reasonable and polite people, you are wrong. They are the same kind of
human beings, like we are here.

> Or recently:
>
>   https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg00687.html
>
> Where they made the ridiculous statement that it is unsafe for Emacs to
> auto-save data in Emacs core if the Wayland compositor shuts down.

There is no assurance whatsoever that you will not get that type of
reaction from a Qt developer. I had similar discussions with highly
competent maintainers of top-tier projects and it requires empathy,
politeness, patience and skillful dialogue. Not to say that this
guarantees success, but starting with the attitude of "I'm obviously
right and you are doing wrong" poses a big risk of a strong-headed
rejection.

Re: Abysmal state of GTK build

[Po Lu]

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

> Suppose you discover that some people are writing customization recipes
> on a popular Wiki page that make use of internal Emacs code for whatever
> purpose, and you know that once you change that code people will come to
> complain about you for breaking their setups.

We will not change such code on purpose, just because someone is writing
customization recipes based on it.  In fact, I would look into making it
"not internal", should it prove useful.

And we will never, ever, resort to name-calling!

> Of course, that's no excuse for calling names on anyone, but otherwise
> what he did is not unreasonable.

All of it is unreasonable.

> Well, I said that he is an occasional contributor after looking at his
> activity map, which is not very colorful.
>
> OTOH, he belonging to the official team may explain why he was not
> censured. That doesn't mean that other team members sympathize with his
> action.

All of the GTK developers do it.  This is the personal experience of
almost everyone who has tried to write real software with GTK.

> There is a bitter disagreement there, for sure. But I've experienced
> worse dealing with KDE/Qt maintainers and I still am a happy KDE user.
> That is, if you think that by switching to Qt you will deal with more
> reasonable and polite people, you are wrong. They are the same kind of
> human beings, like we are here.

I don't think Qt maintainers will proactively seek to break user's
customizations and call them names.

> There is no assurance whatsoever that you will not get that type of
> reaction from a Qt developer. I had similar discussions with highly
> competent maintainers of top-tier projects and it requires empathy,
> politeness, patience and skillful dialogue. Not to say that this
> guarantees success, but starting with the attitude of "I'm obviously
> right and you are doing wrong" poses a big risk of a strong-headed
> rejection.

I've never seen that kind of reaction from a Qt developer, or even a GTK
developer in the 2.x days.  Such behavior is not excusable and
immediately excludes such a toolkit from being suitable for any
software, including Emacs.

Re: Abysmal state of GTK build

[Tim Cross]

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

> Po Lu <luangruo@yahoo.com> writes:
>
>> I guess you misunderstood what I said.  I just said alternatives to X
>> shouldn't be made the default, since almost everyone will be using X for
>> the forseeable future.
>
> The 90% X Firefox user share you mentioned several times was a statistic
> of dubious relevance when it came out 6 months ago and is pretty much
> irrelevant now. The Mozilla Telemetry guys said at the time that it is
> not truly representative, for several reasons. And, more importantly,
> Wayland adoption is gaining momentum, with major distros (such as
> Ubuntu) defaulting to it and KDE joining Gnome as a stable Wayland-based
> desktop environment.
>

I agree. We have to take any analysis based on firefox usage with
caution as despite the importance of firefox wrt free software. it only
Firefox represents a small percentage of users - something which may have even
gotten worse since the move to snap based packaging in Ubuntu which
makes loading firefox excessively slow i.e. 25 - 30 seconds (seems quite
a few people have switched to chromium, brave, qutebrowser etc.) 

The momentum for moving towards Wayland has also greatly benefited from
the resolving of the nvidia issue. Lack of nvidia support in Wayland was
a fairly big impediment for distros switching to Wayland. However,
Fedora 36 comes with nvidia support for wayland. I also suspect the
nvidia announcement about releasing their linux drivers under a dual
GPL/MIT license might also have some impact on nvidia wayland support
(though nvidia doesn't have a good track record here and has gone back
on such announcements in the past IIRC).

> I'll say that by 2025 Wayland will be more popular than X by a wide
> margin, and then X will have a hard time with basic maintenance by lack
> of manpower (some insiders say that it already suffers from that.)
>

There certainly does seem to be some real momentum towards wayland. Not
sure if Wayland will be the more popular by 2025 though. Suspect it may
be the majority of new installations, but existing installs will likely
still be using X and still be the majority. As I tend to see GNU Linux
installs last a lot longer, it could be closer to 2030 before we see
Wayland with a majority of GNU Linux systems, especially as most distros
are unlikely to switch to Wayland as part of a distro update, only
defaulting to Wayland on fresh installs.

There is also a reasonably large user base for non-mainstream window
managers who will stick with X because they want to stick with the WM
they are familiar with - for example the many tiling WMs like awesome,
qtile, xmonad, dwm, stumpwm etc.

> This doesn't mean much for Emacs on the short and medium term. Emacs
> works on XWayland, and XWayland is improving so applications running on
> it doesn't suffer from a degraded user experience compared to native
> Wayland ones, apart from the constraints related to being based on X.
>
> Another claim you made several times is that distros will stop providing
> GTK2 packages soon. This is hard to believe, since other major
> applications (such as GIMP, as you said) also use GTK2 and distros still
> provide packages for libraries way more ancient and obscure than GTK2.
>

Given that some fairly popular DE are still based on GTK2, I'm not
confident it will be removed any time soon. A lot of people have not
been happy with Gnome for some time now, which has resulted in other
desktop environments like mate, cinnamon etc. IIRC a number of these are
still based on GTK2. There are also a couple of reasonably popular
packages still based on GTK2 who are also unhappy with the direction GTK
took from v3 onwards and who have not updated to v3 support. Likely
distros will need to continue GTK2 support for longer than they or the
developers would prefer. 


> Finally, it seems to me that your experience with some GTK developers is
> influencing your technical discussion on this thread.

There does seem to be growing dissatisfaction with X in various
developer communities, especially Gnome and GTK. Some of the criticisms
do seem valid, some less so. I also get a sense from posts in the x.org
community of concerns regarding on-going maintenance, code complexity
and some legacy limitations which are becoming increasingly more
difficult to work around as hardware, environments and user expectations
evolve. However, we also often see how inaccurate predictions about
change can be. I'll bet the Perl community didn't expect Raku (Perl 6)
to take so long to see the light of day or that the move from Python 2
to 3 would be so long and complicated or how challenging nailing the lid
on the IE coffin would be or the fact we still have GNU Linux systems
which only have partial systemd support and lets not mention
IPv6. Personally, I'm quite surprised how far Wayland has got - I
expected much slower progress. The only thing I'm really confident about
is that our predictions are likely more wrong than right and why we must
not bet everything on one winner. 

Re: Abysmal state of GTK build

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> Given that some fairly popular DE are still based on GTK2, I'm not
> confident it will be removed any time soon. A lot of people have not
> been happy with Gnome for some time now, which has resulted in other
> desktop environments like mate, cinnamon etc. IIRC a number of these are
> still based on GTK2. There are also a couple of reasonably popular
> packages still based on GTK2 who are also unhappy with the direction GTK
> took from v3 onwards and who have not updated to v3 support. Likely
> distros will need to continue GTK2 support for longer than they or the
> developers would prefer. 

Cinnamon has always been a GTK 3 desktop environment, and Mate is
apparently now ported to GTK 3 (according to dnf repoquery.)

> There does seem to be growing dissatisfaction with X in various
> developer communities, especially Gnome and GTK.
                         ^^^^^^^^^^

Only.  It's called the "CADT model": www.jwz.org/doc/cadt.html.

> Some of the criticisms do seem valid, some less so. I also get a sense
> from posts in the x.org community of concerns regarding on-going
> maintenance, code complexity and some legacy limitations which are
> becoming increasingly more difficult to work around as hardware,
> environments and user expectations evolve.

The people putting forth those criticisms of X should come up with
something concrete instead of catchy general phrases such as "code
complexity" and "legacy limitations" that other people then throw around
as evidence of problems with X.

Re: Abysmal state of GTK build

[Po Lu]

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

> The 90% X Firefox user share you mentioned several times was a statistic
> of dubious relevance when it came out 6 months ago and is pretty much
> irrelevant now.

6 months ago makes it "irrelevant now"?

> The Mozilla Telemetry guys said at the time that it is not truly
> representative, for several reasons.

Could you find those "several reasons"?

> And, more importantly, Wayland adoption is gaining momentum, with
> major distros (such as Ubuntu) defaulting to it and KDE joining Gnome
> as a stable Wayland-based desktop environment.

It can hardly be called stable (like Wayland in general) when it
implements a different screencast protocol extension from GNOME Shell
and wlroots.

> I'll say that by 2025 Wayland will be more popular than X by a wide
> margin, and then X will have a hard time with basic maintenance by lack
> of manpower (some insiders say that it already suffers from that.)

I will always be available to take up anything that might be missing on
the X server side of things.  But contrary to what people repeat off
internet blogs, the X server is not seeing a lack of maintenance,
manpower, or even new features: XInput 2.4, with support for trackpad
gestures, was released approximately a year ago, which shows that it is
evolving faster than it was during the heyday of X development in the
mid-90s.  X is also a stable and mature system, by nature of its much
more centralized development methodology, meaning that it requires less
manpower to keep working than Wayland, where every feature is preceded
by two to three protocol extensions from different organizations, and
constant changes in the display server are required to keep up with
updates to unstable protocol extensions.

> This doesn't mean much for Emacs on the short and medium term. Emacs
> works on XWayland, and XWayland is improving so applications running on
> it doesn't suffer from a degraded user experience compared to native
> Wayland ones, apart from the constraints related to being based on X.

HiDPI does not work on XWayland.  It is also impossible to actively grab
or warp the pointer.  All of these are very basic problems that have not
yet been solved.

> Another claim you made several times is that distros will stop providing
> GTK2 packages soon. This is hard to believe, since other major
> applications (such as GIMP, as you said) also use GTK2 and distros still
> provide packages for libraries way more ancient and obscure than GTK2.

The GIMP is the last program keeping GTK+ 2.x in package repositories.
Previously, there was also wxWidgets, but almost everyone is in the
process of switching to its GTK 3 backend.

The moment GIMP 3.0 is released, GTK+ 2.x will disappear.

> Finally, it seems to me that your experience with some GTK developers is
> influencing your technical discussion on this thread.

No, not at all.

Re: Abysmal state of GTK build

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> The 90% X Firefox user share you mentioned several times was a statistic
>> of dubious relevance when it came out 6 months ago and is pretty much
>> irrelevant now.
>
> 6 months ago makes it "irrelevant now"?

At the pace things are changing, yes.

>> The Mozilla Telemetry guys said at the time that it is not truly
>> representative, for several reasons.
>
> Could you find those "several reasons"?

On the original source (*) it was mentioned:

  - Some distributions build Firefox with telemetry disabled, which
    might significantly skew the results.

I'll add that there are other significant factors, such as age of
install and release: if you are interested on current trends, you don't
want to take into account relatively old installs such as LTS, Debian
Stable, etc., or even a four months old Ubuntu release, you are mostly
interested on new installs from releases that provides up to date
Wayland packages and asked the user whether to use Wayland, defaulted to
it or provided a simple and prominently advertised method for switching
after the install.

* https://www.phoronix.com/news/Firefox-Wayland-X11-Stats

>> And, more importantly, Wayland adoption is gaining momentum, with
>> major distros (such as Ubuntu) defaulting to it and KDE joining Gnome
>> as a stable Wayland-based desktop environment.
>
> It can hardly be called stable (like Wayland in general) when it
> implements a different screencast protocol extension from GNOME Shell
> and wlroots.

So compatibility with Gnome is what defines the stability of my KDE
install? I just care about not experiencing crashes or defects.

>> I'll say that by 2025 Wayland will be more popular than X by a wide
>> margin, and then X will have a hard time with basic maintenance by lack
>> of manpower (some insiders say that it already suffers from that.)
>
> I will always be available to take up anything that might be missing on
> the X server side of things.

As a happy Emacs/Lucid user: thank you, sincerely. But nobody can assert
"I'll always be here."

> But contrary to what people repeat off
> internet blogs, the X server is not seeing a lack of maintenance,
> manpower, or even new features:

See X Developers Conference 2021, the intervention of Matthieu Herb, for
instance. This is not "people writing on internet blogs."

X is considered legacy and, possibly a worse curse nowadays, unsecure.
For better or worse, new efforts are focused on Wayland. This will have
dire effects over time on X maintenance.

[snip]

>> This doesn't mean much for Emacs on the short and medium term. Emacs
>> works on XWayland, and XWayland is improving so applications running on
>> it doesn't suffer from a degraded user experience compared to native
>> Wayland ones, apart from the constraints related to being based on X.
>
> HiDPI does not work on XWayland.

Scaling produces blurriness on XWayland. That's true, its widely
acknowledged as a problem and people is addressing the issue, slowly.

> It is also impossible to actively grab
> or warp the pointer.  All of these are very basic problems that have not
> yet been solved.

That's the precise issue that is keeping me on X on my multimonitor,
mixed DPI machine.

There is ydotool, which crashes on my system but apparently works for
others. Just two days ago I found some protocols (one from
wayland-protocols, the other from plasma-wayland-protocols) that in
theory allow cursor warping, among other things. I need to figure out
how to use them.

>> Another claim you made several times is that distros will stop providing
>> GTK2 packages soon. This is hard to believe, since other major
>> applications (such as GIMP, as you said) also use GTK2 and distros still
>> provide packages for libraries way more ancient and obscure than GTK2.
>
> The GIMP is the last program keeping GTK+ 2.x in package repositories.

Well, "apt-cache showpkg libgtk2.0-0" shows several hundred dependencies
on my Debian Testing machine.

Re: Abysmal state of GTK build

[Po Lu]

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

> At the pace things are changing, yes.

Sorry, but that's wrong.  6 months is barely enough for a Fedora
release, and definitely not enough for slower-moving GNU/Linux
distributions such as Debian.

> On the original source (*) it was mentioned:
>
>   - Some distributions build Firefox with telemetry disabled, which
>     might significantly skew the results.

"might" doesn't mean "definite".  And it contrasts with my own anecdotal
experience of what people do with GNOME on Wayland.

> I'll add that there are other significant factors, such as age of
> install and release: if you are interested on current trends, you don't
> want to take into account relatively old installs such as LTS, Debian
> Stable, etc., or even a four months old Ubuntu release, you are mostly
> interested on new installs from releases that provides up to date
> Wayland packages and asked the user whether to use Wayland, defaulted to
> it or provided a simple and prominently advertised method for switching
> after the install.
>
> * https://www.phoronix.com/news/Firefox-Wayland-X11-Stats

All I really hear from people is that they install some software, find
out that screencasting does not work, and follow an online guide to log
out and switch to "GNOME on Xorg" instead.

> So compatibility with Gnome is what defines the stability of my KDE
> install? I just care about not experiencing crashes or defects.

No, this is a problem with Wayland in general.  The complete
incompatibility between different compositors.

> See X Developers Conference 2021, the intervention of Matthieu Herb, for
> instance. This is not "people writing on internet blogs."

[...]

> X is considered legacy and, possibly a worse curse nowadays, unsecure.

Sorry, but that only applies if you have no authentication mechanism for
your X server, and have port 6000 exposed to the internet.  Otherwise,
just like under Wayland, programs can only do what their user is
authorized to do.

> For better or worse, new efforts are focused on Wayland. This will have
> dire effects over time on X maintenance.

People can complain all they want, but there are no problems with X due
to those supposedly dire effects.  The difference between X and Wayland
is that X is finished.  There is very little need for maintenance beyond
the occasional build fix, since everything that one could need already
exists, and most rapidly changing components have been devolved out of
the X server (i.e. libinput, DRI/KMS/DRM, et cetera.)

This has already been proven several times.  For example, consider how
adding support for trackpad gestures under Wayland involved a huge
amount of work and bickering over protocol details, while it took only
several hundreds of lines of code in the X server.  Or, consider how
wp_presentation took extremely long to be implemented, and still isn't
available under KWin, while the X Present extension is now available
almost everywhere and is much more flexible (see for example the
target_crtc arg to XPresentRegion, while under Wayland the compositor is
the only program that can determine which output the presentation is
synchronized to, and all compositors I know of simply punt in front of
multiple outputs.)

While under Wayland, problems like screencasting, setting the absolute
position of a toplevel surface, actively grabbing the pointer, or even
warping the pointer, have yet to be solved.  All of this is compounded
by the fact that the reference implementation is not even very good --
for example, it fails to implement constraint adjustments on popups.

> Scaling produces blurriness on XWayland. That's true, its widely
> acknowledged as a problem and people is addressing the issue, slowly.

The problem cannot be addressed correctly due to a fundamental
difference in how scaling works under Wayland and how it works under X.

On X, the X server does not care about scaling.  Everything is done by
the application.  Of course, this does not preclude a mechanism for
making such information known to the compositing manager, such a
_NET_SCALE_FACTOR property that could be put on toplevel windows.

However, on Wayland, the compositor _must_ know about the scale factor
of each buffer committed to a surface, and performs automatic scaling to
the output based on that.  As a result, you can only chose between a
tiny xterm window and correctly scaled LibreOffice, or blurry
everything.

> There is ydotool, which crashes on my system but apparently works for
> others. Just two days ago I found some protocols (one from
> wayland-protocols, the other from plasma-wayland-protocols) that in
> theory allow cursor warping, among other things. I need to figure out
> how to use them.

ydotool is seriously flawed, since it cannot as a matter of principle
know about various things such as the position of toplevel windows.

i.e. how would ydotool implement the equivalent of XKillClient?

> Well, "apt-cache showpkg libgtk2.0-0" shows several hundred dependencies
> on my Debian Testing machine.

They are definitely not important enough to keep GTK+ 2.x there.

In short: Wayland compositors are not ready to become a general
replacement for the X server.  And probably will not in the near future.

That doesn't mean we shouldn't plan ahead, but that we should be
pragmatic and refrain from defaulting to software that is clearly
unready to replace its predecessor and not subject to wide adoption.

And at this point I cannot see what problems Wayland is supposed to
solve, since it is now more fragmented than X was in the 1990s.  The
developers of the reference server are also implementing (unstable, as
usual with Wayland) atrocities such as support for HDCP, which other
compositor developers have thankfully put their foot down on.

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

  > It will not affect Wayland at all, since the Wayland drag-and-drop API
  > is too limited to allow Emacs to implement drag-and-drop properly there.

  > Most importantly, there is no way to cancel drag-and-drop after it
  > begins (think C-g), or to receive a notification when the pointer
  > reenters the frame where it originated after leaving.

That sounds like a serious flaw in Wayland.  Would its developers
want to fix it?  Does it have other UI drawbacks compared with X11,
and would its developers want to fix them?

-- 
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 sounds like a serious flaw in Wayland.  Would its developers
> want to fix it?

Probably not.

> Does it have other UI drawbacks compared with X11, and would its
> developers want to fix them?

The most glaring one is the inability to position toplevel windows
manually, for "security reasons".  The developers don't want to fix it.

Re: Abysmal state of GTK build

[Robert Pluim]

>>>>> On Wed, 24 Aug 2022 12:18:38 +0800, Po Lu <luangruo@yahoo.com> said:

    Po Lu> The most glaring one is the inability to position toplevel windows
    Po Lu> manually, for "security reasons".  The developers don't want to fix it.

I thought it was because the Wayland people have a philosophical
objection to programs knowing anything about the coordinate system in
use. Either way, they donʼt even see it as a problem that needs
fixing.

Robert
-- 

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

  > > That sounds like a serious flaw in Wayland.  Would its developers
  > > want to fix it?

  > Probably not.

Why not?

  > The most glaring one is the inability to position toplevel windows
  > manually, for "security reasons".

I don't quite understand -- what does it mean, concretely, to
"position toplevel windows manually"?  What are "toplevel windows" in
this context?  Is an Emacs frame a toplevel window?  Does this mean
that the user can't move an Emacs frame on the screen?

  > I thought it was because the Wayland people have a philosophical
  > objection to programs knowing anything about the coordinate system in
  > use.

What coordinate system is this about?

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

> Why not?

They object to it based on some poorly defined principle that is a
combination of "security" and something else I can't put my finger on.

>   > The most glaring one is the inability to position toplevel windows
>   > manually, for "security reasons".
>
> I don't quite understand -- what does it mean, concretely, to
> "position toplevel windows manually"?  What are "toplevel windows" in
> this context?  Is an Emacs frame a toplevel window?

Yes.

> Does this mean that the user can't move an Emacs frame on the screen?

No, this means functions like `set-frame-position' can't move the frame
on the screen.  The only way to move the frame is by the user dragging
it with the mouse.

>   > I thought it was because the Wayland people have a philosophical
>   > objection to programs knowing anything about the coordinate system in
>   > use.
>
> What coordinate system is this about?

The coordinate system of the screen.

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

  > > Does this mean that the user can't move an Emacs frame on the screen?

  > No, this means functions like `set-frame-position' can't move the frame
  > on the screen.  The only way to move the frame is by the user dragging
  > it with the mouse.

Thanks.

I don't know whether that limitation is necessary or justified in some way,
but I think that most users don't use `set-frame-position'.
I don't think this will be a big practical problem for users.

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 03 Sep 2022 23:01:31 -0400
> 
>   > No, this means functions like `set-frame-position' can't move the frame
>   > on the screen.  The only way to move the frame is by the user dragging
>   > it with the mouse.
> 
> Thanks.
> 
> I don't know whether that limitation is necessary or justified in some way,
> but I think that most users don't use `set-frame-position'.

Emacs itself uses set-frame-position.  It also moves frames on display
via the 'top' and 'left' frame parameters.  One notable case where
this happens is the desktop.el package, which restores frame and
window configuration of a previous Emacs session.

So I think the inability to do that is quite a big deal for Emacs
users.

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

  > Emacs itself uses set-frame-position.  It also moves frames on display
  > via the 'top' and 'left' frame parameters.  One notable case where
  > this happens is the desktop.el package, which restores frame and
  > window configuration of a previous Emacs session.

  > So I think the inability to do that is quite a big deal for Emacs
  > users.

When we compile the list of disadvantages of various paths forward
for Emacs display on graphics terminals, we should list this
as one disadvantage of Wayland.

-- 
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 Sun, 04 Sep 2022 08:14:54 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Richard Stallman <rms@gnu.org>
    >> Cc: emacs-devel@gnu.org
    >> Date: Sat, 03 Sep 2022 23:01:31 -0400
    >> 
    >> > No, this means functions like `set-frame-position' can't move the frame
    >> > on the screen.  The only way to move the frame is by the user dragging
    >> > it with the mouse.
    >> 
    >> Thanks.
    >> 
    >> I don't know whether that limitation is necessary or justified in some way,
    >> but I think that most users don't use `set-frame-position'.

    Eli> Emacs itself uses set-frame-position.  It also moves frames on display
    Eli> via the 'top' and 'left' frame parameters.  One notable case where
    Eli> this happens is the desktop.el package, which restores frame and
    Eli> window configuration of a previous Emacs session.

And there are packages that want to put frames at specific positions,
such as speedbar (plus the various "pop up frame" packages whose names
I canʼt recall right now)

    Eli> So I think the inability to do that is quite a big deal for Emacs
    Eli> users.

Yes. Itʼs very annoying.


Robert
-- 

Re: Abysmal state of GTK build

[Po Lu]

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

Robert Pluim <rpluim@gmail.com> writes:

> Yes. Itʼs very annoying.

I agree completely.  In the meantime, I have been working on a highly
effective solution for Wayland-only programs (Waydroid comes into mind),
which is to run them under X.

Work in progress code, but worth trying.  Drag-and-drop among Wayland
programs and from Wayland into X does not yet work, along with input
methods and Firefox.  And it is probably buggy.


[-- Attachment #2: Wayland compatibility layer --]
[-- Type: application/gzip, Size: 181032 bytes --]

Emacs As a Wayland WM? Re: Abysmal state of GTK build

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 493 bytes --]

Suppose we: ...

1. Look forward to the Wayland-only world (ie No X) I know that will be
   a while...
2. But suppose, in that world, we could write an Emacs Window Manager
   (whatever that means under Wayland) ...
3 Will things get easier in that somewhat pure world where one doesn't
   have to both look backwards and forwards as we are apparently forced
   to do right now?

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Emacs As a Wayland WM? Re: Abysmal state of GTK build

[Robert Pluim]

>>>>> On Mon, 05 Sep 2022 07:29:59 -0700, "T.V Raman" <raman@google.com> said:

    T> Suppose we: ...
    T> 1. Look forward to the Wayland-only world (ie No X) I know that will be
    T>    a while...
    T> 2. But suppose, in that world, we could write an Emacs Window Manager
    T>    (whatever that means under Wayland) ...
    T> 3 Will things get easier in that somewhat pure world where one doesn't
    T>    have to both look backwards and forwards as we are apparently forced
    T>    to do right now?

I donʼt know about the equivalent of exwm, but forking wlroots and
fixing up some of the more egregious annoyances might be doable.

Robert
-- 

Re: Abysmal state of GTK build

[Daniel Brooks]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sun, 04 Sep 2022 08:14:54 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
>     >> From: Richard Stallman <rms@gnu.org>
>     >> Cc: emacs-devel@gnu.org
>     >> Date: Sat, 03 Sep 2022 23:01:31 -0400
>     >> 
>     >> > No, this means functions like `set-frame-position' can't move the frame
>     >> > on the screen.  The only way to move the frame is by the user dragging
>     >> > it with the mouse.
>     >> 
>     >> Thanks.
>     >> 
>     >> I don't know whether that limitation is necessary or justified in some way,
>     >> but I think that most users don't use `set-frame-position'.
>
>     Eli> Emacs itself uses set-frame-position.  It also moves frames on display
>     Eli> via the 'top' and 'left' frame parameters.  One notable case where
>     Eli> this happens is the desktop.el package, which restores frame and
>     Eli> window configuration of a previous Emacs session.
>
> And there are packages that want to put frames at specific positions,
> such as speedbar (plus the various "pop up frame" packages whose names
> I canʼt recall right now)
>
>     Eli> So I think the inability to do that is quite a big deal for Emacs
>     Eli> users.
>
> Yes. Itʼs very annoying.

Don’t forget about emacs --geometry, which sets top/left/width/height
properties on the initial-frame-alist.

db48x

RE: [External] : Re: Abysmal state of GTK build

[Drew Adams]

> > > No, this means functions like `set-frame-position' can't move the
> > > frame on the screen.  The only way to move the frame is by the user
> > > dragging it with the mouse.
> >
> > Thanks.
> >
> > I don't know whether that limitation is necessary or justified in some
> > way, but I think that most users don't use `set-frame-position'.
> 
> Emacs itself uses set-frame-position.  It also moves frames on display
> via the 'top' and 'left' frame parameters.  One notable case where
> this happens is the desktop.el package, which restores frame and
> window configuration of a previous Emacs session.
> 
> So I think the inability to do that is quite a big deal for Emacs
> users.

+1.

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

  > How much of an issue will this be on Wayland systems? Considering GTK4
  > will probably drop X11 support, and Fedora, Debian and Ubuntu (likely
  > covering vast majority of GNU/Linux desktop) are Wayland default,

Could they help us convince or help the Wayland developers to
make the desirable improvements in Wayland?

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

[Payas Relekar]

Richard Stallman <rms@gnu.org> writes:

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

GTK3 is already on the way out, as GTK4 is being ready for release.

There is a good reason why MATE moved to GTK3 after it began (more or less) as
Gnome2+GTK2 fork. Maintaining a library like GTK is not easy,
particularly for small development teams already spread thin on their
primary project (building/maintaining Desktop Environment). That is also
the reason why there are very few credible options on native UI toolkit
beyond GTK and Qt.

Regards,
Payas

--

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

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

  > GTK3 is already on the way out, as GTK4 is being ready for release.

I don't think this changes the issue.  If they want to use GTK 4,
just replace "3" with "4" in what I said.

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

[Payas Relekar]

Po Lu <luangruo@yahoo.com> writes:

> What makes you think the GTK developers will be able to dictate what
> people will use?

While I hope for otherwise, and this is not the place to discuss this,
general trend in Linux land over past decade or so is that once Gnome
blesses something as default, it tends to be blessed by others as well.

> Remember that if the world revolved around their decisions, we would all
> be clowns occupying a peanut gallery.

:) I tend to agree here, but this discussion is veering off-topic.

>> That is unfortunate. Considering HiDPI + mixed DPI support is
>> non-existent in X11, I was really hoping Wayland feature bulimia to be
>> solved/on-way-to-be-solved problem by now.
>
> Why do you think that's so?  On X, the X server says nothing about the
> scale of a window, screen, or the part of a screen taken by a monitor.
> A program can simply rescale itself as it moves across different
> outputs.
>
> I think the reason people think HiDPI support doesn't work on X is that
> it doesn't work in Xwayland, which is strictly a problem with that, and
> is not seen on bare-metal X.

I only have personal experience, so apologies in advance if I miss
something obvious. I use Plasma desktop (used Gnome for years before)
on my laptop as no-frills feature rich Desktop Environment. I do not
like messing around with Xresources and like things to Just Work™.

My laptop display is plain old 15" 1080p, but usually connect with
external monitor (27" 4K). On X11 there is no option for external
display except 1080p so all the pixels go to waste. Only on Wayland can
I select 4K and different DPI settings (125% on laptop display + 175% on
external). From what I've read this is fairly consistent with other
people's experiences.

As you mention, there is probably a way to get X11 to behave the same,
but if this option is not straightforward enough to be implemented and
made available by a DE as config-loaded as Plasma then we can safely
consider it to be out of skill/interest of majority of computer users.

>> That is fair. From what I understand Wayland support on non-Linux
>> systems is still imperfect at best so X11 support is here to
>> stay. But, can we have it as non-default and get away with it for the
>> most part?
>
> No.  AFAIK it was recently discovered that less than 10% of Firefox
> users on non-macOS Unix systems were using Wayland or Xwayland.

Good point. But this discussion focuses more on future that status quo.

>> Apologies for simple (and possibly stupid) questions, but GTK
>> situation has more thorns than I previously thought. Considering WSL2
>> will have more people using Emacs via Wayland/Pgtk making defaults
>> more important.
>
> I don't think supporting the PGTK build on MS Windows is a good idea at
> all.

Oh no, perhaps I misspoke. WSL2 is basically a Linux VM that comes built
into Windows 11. The Emacs runs on Linux, uses Linux sys-calls to talk
to Linux kernel, and renders PGTK build on Wayland. The VM then uses a
custom RDP to integrate Emacs window with the parent Windows OS.

I only mentioned it because this particular implementation of RDP only
works with Wayland natively and X11 applications are second class via
XWayland.

I can provide some more resources if you'd like, but generally searching
WSL2 and following links to MS documentation is sufficient.


Having said all of the above, I am not an Emacs maintainer. Po/Eli/Lars
have much better understanding and obvious say for good reasons. I am
only here to provide alternate perspective.

Thanks,
Payas

--

Re: Abysmal state of GTK build

[Po Lu]

Payas Relekar <relekarpayas@gmail.com> writes:

> I only have personal experience, so apologies in advance if I miss
> something obvious. I use Plasma desktop (used Gnome for years before)
> on my laptop as no-frills feature rich Desktop Environment. I do not
> like messing around with Xresources and like things to Just Work™.
>
> My laptop display is plain old 15" 1080p, but usually connect with
> external monitor (27" 4K). On X11 there is no option for external
> display except 1080p so all the pixels go to waste. Only on Wayland can
> I select 4K and different DPI settings (125% on laptop display + 175% on
> external). From what I've read this is fairly consistent with other
> people's experiences.

All of those options... aren't actually part of X.  Including Xft.dpi
and such.  There could easily also be a mapping between CRTC identifiers
and scale factors in xsettings.

> As you mention, there is probably a way to get X11 to behave the same,
> but if this option is not straightforward enough to be implemented and
> made available by a DE as config-loaded as Plasma then we can safely
> consider it to be out of skill/interest of majority of computer users.

External monitors aside, HiDPI works fine on most X desktop environments
(I don't know about Plasma) out of the box.

> Good point. But this discussion focuses more on future that status quo.

When will that future be, if under Wayland the protocols for input
methods, server-side decorations and output management (for which there
are actually multiple protocols) are still unstable?

> Oh no, perhaps I misspoke. WSL2 is basically a Linux VM that comes built
                                                 ^^^^^
Did you mean GNU/Linux?

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

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

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?