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

[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

[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

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

[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

[Ó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]

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

[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

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

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

> 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

[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

[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

[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

[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

[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

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

[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