MPS and pgtk

MPS and pgtk

[Aleksandr Vityazev]

Hello,

I tried to build scratch/igc with the "--with-pgtk" flag
got the following errors:

make[3]: Leaving directory '/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/admin/unidata'
  CCLD     temacs
ld: pgtkterm.o: in function `mark_pgtkterm':
/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:357: undefined reference to `mark_object'
ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:358: undefined reference to `mark_object'
ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:359: undefined reference to `mark_object'
ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:360: undefined reference to `mark_object'
ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:361: undefined reference to `mark_object'
ld: pgtkterm.o:/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:369: more undefined references to `mark_object' follow
collect2: error: ld returned 1 exit status

The remaining configuration flags were as follows:
--with-mps=yes
--with-cairo
--with-modules
--with-native-compilation=no
--disable-build-details

-- 
Best regards,
Aleksandr Vityazev

Re: MPS and pgtk

[Gerd Möllmann]

Aleksandr Vityazev <avityazev@disroot.org> writes:

> Hello,
>
> I tried to build scratch/igc with the "--with-pgtk" flag
> got the following errors:
>
> make[3]: Leaving directory '/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/admin/unidata'
>   CCLD     temacs
> ld: pgtkterm.o: in function `mark_pgtkterm':
> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:357: undefined reference to `mark_object'
> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:358: undefined reference to `mark_object'
> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:359: undefined reference to `mark_object'
> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:360: undefined reference to `mark_object'
> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:361: undefined reference to `mark_object'
> ld: pgtkterm.o:/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:369: more undefined references to `mark_object' follow
> collect2: error: ld returned 1 exit status
>
> The remaining configuration flags were as follows:
> --with-mps=yes
> --with-cairo
> --with-modules
> --with-native-compilation=no
> --disable-build-details

Looks like pgtk is currently not supported, i.e. apparenlty no one
working on igc is using it, sorry.

Re: MPS and pgtk

[Ergus]

On Wed, Jun 26, 2024 at 06:38:03PM GMT, Gerd M�llmann wrote:
>Aleksandr Vityazev <avityazev@disroot.org> writes:
>
>> Hello,
>>
>> I tried to build scratch/igc with the "--with-pgtk" flag
>> got the following errors:
>>
>> make[3]: Leaving directory '/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/admin/unidata'
>>   CCLD     temacs
>> ld: pgtkterm.o: in function `mark_pgtkterm':
>> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:357: undefined reference to `mark_object'
>> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:358: undefined reference to `mark_object'
>> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:359: undefined reference to `mark_object'
>> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:360: undefined reference to `mark_object'
>> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:361: undefined reference to `mark_object'
>> ld: pgtkterm.o:/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:369: more undefined references to `mark_object' follow
>> collect2: error: ld returned 1 exit status
>>
>> The remaining configuration flags were as follows:
>> --with-mps=yes
>> --with-cairo
>> --with-modules
>> --with-native-compilation=no
>> --disable-build-details
>
>Looks like pgtk is currently not supported, i.e. apparenlty no one
>working on igc is using it, sorry.
>
This is wondering me because all the main distributions/desktops are
moving (or have already moved) to Wayland.

So, IMHO the pgtk support may be prioritized as it is the only way we
support Wayland natively.

Not sure if there are plans or alternatives under consideration to
change/improve pgtk, but if igc becomes an issue for it... we may
rethink if we really want it looking to the future?

WDYT?
Ergus

Re: MPS and pgtk

[Fejfighter]

[-- Attachment #1.1: Type: text/plain, Size: 2471 bytes --]

I have been loosely tracking the branch, but not with much time to actively
participate.

Here's a simple patch that will get Aleksandr past the compile issue.
I think there are still a couple of places that may catch out parts of
gtk/wayland, but this is usually stable for a few minutes.
But this branch is fast moving so it's hard to track what's unique.

On Thu, Jun 27, 2024 at 8:39 AM Ergus <spacibba@aol.com> wrote:

> On Wed, Jun 26, 2024 at 06:38:03PM GMT, Gerd M�llmann wrote:
> >Aleksandr Vityazev <avityazev@disroot.org> writes:
> >
> >> Hello,
> >>
> >> I tried to build scratch/igc with the "--with-pgtk" flag
> >> got the following errors:
> >>
> >> make[3]: Leaving directory
> '/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/admin/unidata'
> >>   CCLD     temacs
> >> ld: pgtkterm.o: in function `mark_pgtkterm':
> >>
> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:357:
> undefined reference to `mark_object'
> >> ld:
> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:358:
> undefined reference to `mark_object'
> >> ld:
> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:359:
> undefined reference to `mark_object'
> >> ld:
> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:360:
> undefined reference to `mark_object'
> >> ld:
> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:361:
> undefined reference to `mark_object'
> >> ld:
> pgtkterm.o:/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:369:
> more undefined references to `mark_object' follow
> >> collect2: error: ld returned 1 exit status
> >>
> >> The remaining configuration flags were as follows:
> >> --with-mps=yes
> >> --with-cairo
> >> --with-modules
> >> --with-native-compilation=no
> >> --disable-build-details
> >
> >Looks like pgtk is currently not supported, i.e. apparenlty no one
> >working on igc is using it, sorry.
> >
> This is wondering me because all the main distributions/desktops are
> moving (or have already moved) to Wayland.
>
> So, IMHO the pgtk support may be prioritized as it is the only way we
> support Wayland natively.
>
> Not sure if there are plans or alternatives under consideration to
> change/improve pgtk, but if igc becomes an issue for it... we may
> rethink if we really want it looking to the future?
>
> WDYT?
> Ergus
>
>

[-- Attachment #1.2: Type: text/html, Size: 3121 bytes --]

[-- Attachment #2: 0001-src-pgtkterm.c-mark_pgtkterm-exclude-from-MPS-builds.patch --]
[-- Type: text/x-patch, Size: 681 bytes --]

From 308ccb6145f390168f842f1b4135e0868d48d68b Mon Sep 17 00:00:00 2001
From: Jeff Walsh <fejfighter@gmail.com>
Date: Wed, 29 May 2024 12:40:03 +1000
Subject: [PATCH] * src/pgtkterm.c (mark_pgtkterm): exclude from MPS builds

---
 src/pgtkterm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 49b7ea406f8..7279f5d863b 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -336,6 +336,7 @@ evq_flush (struct input_event *hold_quit)
   return n;
 }
 
+#ifndef HAVE_MPS
 void
 mark_pgtkterm (void)
 {
@@ -369,6 +370,7 @@ mark_pgtkterm (void)
 	mark_object (device->name);
     }
 }
+#endif
 
 char *
 get_keysym_name (int keysym)
-- 
2.45.2

Re: MPS and pgtk

[Gerd Möllmann]

Fejfighter <fejfighter@gmail.com> writes:

> Here's a simple patch that will get Aleksandr past the compile issue.
> I think there are still a couple of places that may catch out parts of gtk/wayland, but this is usually stable for a few minutes.
> But this branch is fast moving so it's hard to track what's unique. 

Thanks. I'll leave applying that patch to the Emacs maintainers because
of the copyright checking thing, you know what I mean.

Re: MPS and pgtk

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Ergus <spacibba@aol.com>,  Aleksandr Vityazev <avityazev@disroot.org>,
>   emacs-devel@gnu.org,  Eli Zaretskii <eliz@gnu.org>,
>   eller.helmut@gmail.com
> Date: Thu, 27 Jun 2024 05:59:39 +0200
> 
> Fejfighter <fejfighter@gmail.com> writes:
> 
> > Here's a simple patch that will get Aleksandr past the compile issue.
> > I think there are still a couple of places that may catch out parts of gtk/wayland, but this is usually stable for a few minutes.
> > But this branch is fast moving so it's hard to track what's unique. 
> 
> Thanks. I'll leave applying that patch to the Emacs maintainers because
> of the copyright checking thing, you know what I mean.

Jeff's assignment is on file, so no copyright issues here.

I installed the change on the branch.

Re: MPS and pgtk

[Helmut Eller]

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

On Thu, Jun 27 2024, Eli Zaretskii wrote:

> Jeff's assignment is on file, so no copyright issues here.
>
> I installed the change on the branch.

Here's another one that is needed to avoid crashes when pressing the
scrollbar.  The other patch is for the tty version; it has nothing to do
with pgtk.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-tty_list-a-root.patch --]
[-- Type: text/x-diff, Size: 2059 bytes --]

From 840e28c742a9fed9e18769703ff609d7dae2c6ee Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@gmail.com>
Date: Thu, 27 Jun 2024 16:27:45 +0200
Subject: [PATCH 1/2] Make tty_list a root

* src/igc.c (scan_tty_list, root_create_tty_list): New.
(make_igc): Make tty_list an exact root.
---
 src/igc.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/src/igc.c b/src/igc.c
index 6a924a654f6..c960dde3c05 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -48,6 +48,7 @@
 #include "thread.h"
 #include "treesit.h"
 #include "puresize.h"
+#include "termchar.h"
 #ifdef HAVE_WINDOW_SYSTEM
 #include TERM_HEADER
 #endif /* HAVE_WINDOW_SYSTEM */
@@ -1236,6 +1237,24 @@ scan_ptr_exact (mps_ss_t ss, void *start, void *end, void *closure)
   return MPS_RES_OK;
 }
 
+static mps_res_t
+scan_tty_list (mps_ss_t ss, void *start, void *end, void *closure)
+{
+  igc_assert (start == &tty_list);
+  igc_assert (end == (&tty_list) + 1);
+  MPS_SCAN_BEGIN (ss)
+  {
+    for (struct tty_display_info *tty = tty_list; tty; tty = tty->next)
+      {
+	IGC_FIX12_RAW (ss, &tty->terminal);
+	IGC_FIX12_OBJ (ss, &tty->top_frame);
+	IGC_FIX12_RAW (ss, &tty->previous_frame);
+      }
+  }
+  MPS_SCAN_END (ss);
+  return MPS_RES_OK;
+}
+
 /***********************************************************************
 			 Default pad, fwd, ...
  ***********************************************************************/
@@ -2275,6 +2294,13 @@ root_create_terminal_list (struct igc *gc)
   root_create_ambig (gc, start, end, "terminal-list");
 }
 
+static void
+root_create_tty_list (struct igc *gc)
+{
+  root_create_exact (gc, &tty_list, (&tty_list) + 1,
+		     scan_tty_list, "tty-list");
+}
+
 static void
 root_create_main_thread (struct igc *gc)
 {
@@ -3952,6 +3978,7 @@ make_igc (void)
   root_create_staticvec (gc);
   root_create_lispsym (gc);
   root_create_terminal_list (gc);
+  root_create_tty_list (gc);
   root_create_main_thread (gc);
   root_create_exact_ptr (gc, &current_thread);
   root_create_exact_ptr (gc, &all_threads);
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Fix-scrollbars-for-pgtk.patch --]
[-- Type: text/x-diff, Size: 1337 bytes --]

From ae8052a7838217bf45e1cd916b0ec8452c4623ca Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@gmail.com>
Date: Thu, 27 Jun 2024 20:50:08 +0200
Subject: [PATCH 2/2] Fix scrollbars for pgtk

* src/pgtkterm.c (xg_scroll_callback, xg_end_scroll_callback)[HAVE_MPS]:
Load the scroll-bar from the cell.
---
 src/pgtkterm.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 7279f5d863b..7ec0969a14b 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -3953,7 +3953,12 @@ xg_scroll_callback (GtkRange * range,
 		    GtkScrollType scroll, gdouble value, gpointer user_data)
 {
   int whole = 0, portion = 0;
+#ifdef HAVE_MPS
+  struct scroll_bar **bar_cell = user_data;
+  struct scroll_bar *bar = *bar_cell;
+#else
   struct scroll_bar *bar = user_data;
+#endif
   enum scroll_bar_part part = scroll_bar_nowhere;
   GtkAdjustment *adj = GTK_ADJUSTMENT (gtk_range_get_adjustment (range));
 
@@ -4019,7 +4024,12 @@ xg_scroll_callback (GtkRange * range,
 xg_end_scroll_callback (GtkWidget *widget,
 			GdkEventButton *event, gpointer user_data)
 {
+#ifdef HAVE_MPS
+  struct scroll_bar **bar_cell = user_data;
+  struct scroll_bar *bar = *bar_cell;
+#else
   struct scroll_bar *bar = user_data;
+#endif
   bar->dragging = -1;
   if (WINDOWP (window_being_scrolled))
     {
-- 
2.39.2

Re: MPS and pgtk

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Thu, Jun 27 2024, Eli Zaretskii wrote:
>
>> Jeff's assignment is on file, so no copyright issues here.
>>
>> I installed the change on the branch.
>
> Here's another one that is needed to avoid crashes when pressing the
> scrollbar.  The other patch is for the tty version; it has nothing to do
> with pgtk.

Thanks, and almost pushed, but gnu.org seems to be down again.

Re: MPS and pgtk

[Gerd Möllmann]

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

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> On Thu, Jun 27 2024, Eli Zaretskii wrote:
>>
>>> Jeff's assignment is on file, so no copyright issues here.
>>>
>>> I installed the change on the branch.
>>
>> Here's another one that is needed to avoid crashes when pressing the
>> scrollbar.  The other patch is for the tty version; it has nothing to do
>> with pgtk.
>
> Thanks, and almost pushed, but gnu.org seems to be down again.

And pushed.

Re: MPS and pgtk

[Gerd Möllmann]

Ergus <spacibba@aol.com> writes:

>>Looks like pgtk is currently not supported, i.e. apparenlty no one
>>working on igc is using it, sorry.
>>
> This is wondering me because all the main distributions/desktops are
> moving (or have already moved) to Wayland.
>
> So, IMHO the pgtk support may be prioritized as it is the only way we
> support Wayland natively.
>
> Not sure if there are plans or alternatives under consideration to
> change/improve pgtk, but if igc becomes an issue for it... we may
> rethink if we really want it looking to the future?
>
> WDYT?

The only thing I prioritize for myself is macOS and that in my fork with
CL packages :-). Also, the idea that an experimental branch that is
developed mainly by 2 people should prioritize such things is funny. And
finally, the assumption that igc has a problem with pgtk or the other
way around is false.

Re: MPS and pgtk

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Aleksandr Vityazev <avityazev@disroot.org>,  emacs-devel@gnu.org,  Eli
>  Zaretskii <eliz@gnu.org>,  eller.helmut@gmail.com
> Date: Thu, 27 Jun 2024 05:57:27 +0200
> 
> Ergus <spacibba@aol.com> writes:
> 
> >>Looks like pgtk is currently not supported, i.e. apparenlty no one
> >>working on igc is using it, sorry.
> >>
> > This is wondering me because all the main distributions/desktops are
> > moving (or have already moved) to Wayland.
> >
> > So, IMHO the pgtk support may be prioritized as it is the only way we
> > support Wayland natively.
> >
> > Not sure if there are plans or alternatives under consideration to
> > change/improve pgtk, but if igc becomes an issue for it... we may
> > rethink if we really want it looking to the future?
> >
> > WDYT?
> 
> The only thing I prioritize for myself is macOS and that in my fork with
> CL packages :-). Also, the idea that an experimental branch that is
> developed mainly by 2 people should prioritize such things is funny. And
> finally, the assumption that igc has a problem with pgtk or the other
> way around is false.

Let me rephrase this in a more positive way: people who are interested
in having the PGTK build work with MPS are encouraged to come on
board, track this branch's development and the related discussions,
and contribute ideas and patches for that configuration of Emacs.
That's the only way of making sure the branch works with the PGTK
build; it is not a question of changing priorities, because no one of
those currently involved is intentionally neglecting PGTK in this
respect.

Re: MPS and pgtk

[Eli Zaretskii]

> Date: Thu, 27 Jun 2024 00:38:06 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Aleksandr Vityazev <avityazev@disroot.org>, emacs-devel@gnu.org, 
> 	Eli Zaretskii <eliz@gnu.org>, eller.helmut@gmail.com
> 
> On Wed, Jun 26, 2024 at 06:38:03PM GMT, Gerd M�llmann wrote:
> >Aleksandr Vityazev <avityazev@disroot.org> writes:
> >
> >> Hello,
> >>
> >> I tried to build scratch/igc with the "--with-pgtk" flag
> >> got the following errors:
> >>
> >> make[3]: Leaving directory '/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/admin/unidata'
> >>   CCLD     temacs
> >> ld: pgtkterm.o: in function `mark_pgtkterm':
> >> /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:357: undefined reference to `mark_object'
> >> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:358: undefined reference to `mark_object'
> >> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:359: undefined reference to `mark_object'
> >> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:360: undefined reference to `mark_object'
> >> ld: /tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:361: undefined reference to `mark_object'
> >> ld: pgtkterm.o:/tmp/guix-build-emacs-igc-31.0.50-0.544e031.drv-0/source/src/pgtkterm.c:369: more undefined references to `mark_object' follow
> >> collect2: error: ld returned 1 exit status
> >>
> >> The remaining configuration flags were as follows:
> >> --with-mps=yes
> >> --with-cairo
> >> --with-modules
> >> --with-native-compilation=no
> >> --disable-build-details
> >
> >Looks like pgtk is currently not supported, i.e. apparenlty no one
> >working on igc is using it, sorry.
> >
> This is wondering me because all the main distributions/desktops are
> moving (or have already moved) to Wayland.

Which is bothersome, at least from the Emacs POV, since Wayland and
PGTK have so many limitations, restrictions, and misfeatures which
effectively disable useful Emacs features.

> So, IMHO the pgtk support may be prioritized as it is the only way we
> support Wayland natively.
> 
> Not sure if there are plans or alternatives under consideration to
> change/improve pgtk, but if igc becomes an issue for it... we may
> rethink if we really want it looking to the future?

Given the sorry state of Wayland and GTK support of what Emacs needs,
from my POV the PGTK configuration becomes less and less relevant to
Emacs.  I'm aware that the world moves in the opposite direction, but
unless we get some help from Wayland/GTK developers, or,
alternatively, find ways to work around those limitations (unlikely,
IMNSHO), there's nothing we can do about this, and nothing we could
gain by "rethinking".  If you care about these platforms, start
lobbying the respective development teams to cater more for Emacs and
its needs.

Sorry.

Re: MPS and pgtk

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Which is bothersome, at least from the Emacs POV, since Wayland and
> PGTK have so many limitations, restrictions, and misfeatures which
> effectively disable useful Emacs features.
>
>> So, IMHO the pgtk support may be prioritized as it is the only way we
>> support Wayland natively.
>> 
>> Not sure if there are plans or alternatives under consideration to
>> change/improve pgtk, but if igc becomes an issue for it... we may
>> rethink if we really want it looking to the future?
>
> Given the sorry state of Wayland and GTK support of what Emacs needs,
> from my POV the PGTK configuration becomes less and less relevant to
> Emacs.  I'm aware that the world moves in the opposite direction, but
> unless we get some help from Wayland/GTK developers, or,
> alternatively, find ways to work around those limitations (unlikely,
> IMNSHO), there's nothing we can do about this, and nothing we could
> gain by "rethinking".  If you care about these platforms, start
> lobbying the respective development teams to cater more for Emacs and
> its needs.
>
> Sorry.

The silver lining is that I very much doubt PGTK will pose special
difficulties for MPS support.

Re: MPS and pgtk

[Arsen Arsenović]

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

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> So, IMHO the pgtk support may be prioritized as it is the only way we
>> support Wayland natively.
>> 
>> Not sure if there are plans or alternatives under consideration to
>> change/improve pgtk, but if igc becomes an issue for it... we may
>> rethink if we really want it looking to the future?
>
> Given the sorry state of Wayland and GTK support of what Emacs needs,
> from my POV the PGTK configuration becomes less and less relevant to
> Emacs.  I'm aware that the world moves in the opposite direction, but
> unless we get some help from Wayland/GTK developers, or,
> alternatively, find ways to work around those limitations (unlikely,
> IMNSHO), there's nothing we can do about this, and nothing we could
> gain by "rethinking".  If you care about these platforms, start
> lobbying the respective development teams to cater more for Emacs and
> its needs.

I am curious about what these are, as I am quite interested in the
further development of Wayland.  IMO, X has overstayed its welcome, as
it is flawed from the ground up, visibly (to the point where I was quite
surprised the other day when I opened an X session to find noticeable
issues handling mixed refresh rate, and flickering when windows were
changing sizes or opening/closing).

I am aware of the GTK issues of not being able to multihead or handle
disconnects, but the only Wayland one I am aware of is lack of a way to
know which frames are visible (which I don't see as a big issue.. and it
is perhaps fixable anyway).

WRT GTK, I've considered Qt (but have not seen yet whether it has the
same restrictions) and multiprocessing the UI, but have not had time to
look into those options yet.  Has anyone lese considered Qt?
-- 
Arsen Arsenović

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

Re: MPS and pgtk

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Ergus <spacibba@aol.com>,  gerd.moellmann@gmail.com,
>   avityazev@disroot.org,  emacs-devel@gnu.org,  eller.helmut@gmail.com
> Date: Thu, 27 Jun 2024 12:19:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> So, IMHO the pgtk support may be prioritized as it is the only way we
> >> support Wayland natively.
> >> 
> >> Not sure if there are plans or alternatives under consideration to
> >> change/improve pgtk, but if igc becomes an issue for it... we may
> >> rethink if we really want it looking to the future?
> >
> > Given the sorry state of Wayland and GTK support of what Emacs needs,
> > from my POV the PGTK configuration becomes less and less relevant to
> > Emacs.  I'm aware that the world moves in the opposite direction, but
> > unless we get some help from Wayland/GTK developers, or,
> > alternatively, find ways to work around those limitations (unlikely,
> > IMNSHO), there's nothing we can do about this, and nothing we could
> > gain by "rethinking".  If you care about these platforms, start
> > lobbying the respective development teams to cater more for Emacs and
> > its needs.
> 
> I am curious about what these are, as I am quite interested in the
> further development of Wayland.

Search our etc/PROBLEMS file for "pgtk", and you will see many of
them.  Others are in the various bug reports, so searching debbugs for
PGTK might uncover them.

> WRT GTK, I've considered Qt (but have not seen yet whether it has the
> same restrictions) and multiprocessing the UI, but have not had time to
> look into those options yet.  Has anyone lese considered Qt?

Yes, it's in the archives.  For starters, it's a C++ toolkit, but
AFAIR there were other problems as well.

Re: MPS and pgtk

[Konstantin Kharlamov]

On Thu, 2024-06-27 at 13:36 +0300, Eli Zaretskii wrote:
> > From: Arsen Arsenović <arsen@aarsen.me>
> > WRT GTK, I've considered Qt (but have not seen yet whether it has
> > the
> > same restrictions) and multiprocessing the UI, but have not had
> > time to
> > look into those options yet.  Has anyone lese considered Qt?
> 
> Yes, it's in the archives.  For starters, it's a C++ toolkit, but
> AFAIR there were other problems as well.

Just wanted to mention there's also a EFL toolkit, written in C. It
seems to be little known as well as the Enlightenment DE that uses the
toolkit (a very beautiful DE tho, but that besides the point). It has
Wayland support, although Idk how well it's tested given it's not a
well known project. EFL and Enlightenment was developed by Samsung.

Re: MPS and pgtk

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> I am curious about what these are, as I am quite interested in the
> further development of Wayland.  IMO, X has overstayed its welcome, as
> it is flawed from the ground up, visibly (to the point where I was quite
> surprised the other day when I opened an X session to find noticeable
> issues handling mixed refresh rate, and flickering when windows were
> changing sizes or opening/closing).

At fault is probably your X compositing manager or poor engineering in
he client, not the X server, and least of all the extensible X
protocol...

> I am aware of the GTK issues of not being able to multihead or handle
> disconnects, but the only Wayland one I am aware of is lack of a way to
> know which frames are visible (which I don't see as a big issue.. and it
> is perhaps fixable anyway).

If Emacs is to be satisfactory citizen of the Wayland desktop,
facilities for moving frames on the virtual desktop and reading their
positions are a non-negotiable must.  It's really too bad that this is
literally anathema to Wayland's designers as one of the putative
misdesigns of X they chose to target for eradication.  This of all
things!

Gracefully responding to disconnects, and suchlike, are deficiencies in
GTK that will be addressed if and when I determine to commit myself to
implementing a Wayland terminal backend independent of all but the
Wayland client libraries and protocol definitions, though, needless to
say, no tears will be shed if anyone will undertake this now.

> WRT GTK, I've considered Qt (but have not seen yet whether it has the
> same restrictions) and multiprocessing the UI, but have not had time to
> look into those options yet.  Has anyone lese considered Qt?

Qt is equally incapable of responding to interruptions to display
connections, AFAIK.

Re: MPS and pgtk

[Björn Bidar]

Arsen Arsenović <arsen@aarsen.me> writes:

> Hi,
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> So, IMHO the pgtk support may be prioritized as it is the only way we
>>> support Wayland natively.
>>> 
>>> Not sure if there are plans or alternatives under consideration to
>>> change/improve pgtk, but if igc becomes an issue for it... we may
>>> rethink if we really want it looking to the future?
>>
>> Given the sorry state of Wayland and GTK support of what Emacs needs,
>> from my POV the PGTK configuration becomes less and less relevant to
>> Emacs.  I'm aware that the world moves in the opposite direction, but
>> unless we get some help from Wayland/GTK developers, or,
>> alternatively, find ways to work around those limitations (unlikely,
>> IMNSHO), there's nothing we can do about this, and nothing we could
>> gain by "rethinking".  If you care about these platforms, start
>> lobbying the respective development teams to cater more for Emacs and
>> its needs.
>
> I am curious about what these are, as I am quite interested in the
> further development of Wayland.  IMO, X has overstayed its welcome, as
> it is flawed from the ground up, visibly (to the point where I was quite
> surprised the other day when I opened an X session to find noticeable
> issues handling mixed refresh rate, and flickering when windows were
> changing sizes or opening/closing).

The biggest issue is IMHO the GTK developers as they limit the GDK
Wayland backend to the protocols that want and not what someone behind
their horizon want.

Some feature Emacs wants like to know on which desktop a window is are
against what the GNOME people thing Wayland should be.

> I am aware of the GTK issues of not being able to multihead or handle
> disconnects, but the only Wayland one I am aware of is lack of a way to
> know which frames are visible (which I don't see as a big issue.. and it
> is perhaps fixable anyway).

There are patches to handle disconnects in GTK4, it could be possible to
port it back.

> WRT GTK, I've considered Qt (but have not seen yet whether it has the
> same restrictions) and multiprocessing the UI, but have not had time to
> look into those options yet.  Has anyone lese considered Qt?

Re: MPS and pgtk

[Daniel Colascione]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Hi,
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> So, IMHO the pgtk support may be prioritized as it is the only way we
>>>> support Wayland natively.
>>>> 
>>>> Not sure if there are plans or alternatives under consideration to
>>>> change/improve pgtk, but if igc becomes an issue for it... we may
>>>> rethink if we really want it looking to the future?
>>>
>>> Given the sorry state of Wayland and GTK support of what Emacs needs,
>>> from my POV the PGTK configuration becomes less and less relevant to
>>> Emacs.  I'm aware that the world moves in the opposite direction, but
>>> unless we get some help from Wayland/GTK developers, or,
>>> alternatively, find ways to work around those limitations (unlikely,
>>> IMNSHO), there's nothing we can do about this, and nothing we could
>>> gain by "rethinking".  If you care about these platforms, start
>>> lobbying the respective development teams to cater more for Emacs and
>>> its needs.
>>
>> I am curious about what these are, as I am quite interested in the
>> further development of Wayland.  IMO, X has overstayed its welcome, as
>> it is flawed from the ground up, visibly (to the point where I was quite
>> surprised the other day when I opened an X session to find noticeable
>> issues handling mixed refresh rate, and flickering when windows were
>> changing sizes or opening/closing).
>
> The biggest issue is IMHO the GTK developers as they limit the GDK
> Wayland backend to the protocols that want and not what someone behind
> their horizon want.
>
> Some feature Emacs wants like to know on which desktop a window is are
> against what the GNOME people thing Wayland should be.

Could just fork GTK.

Re: MPS and pgtk

[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 biggest issue is IMHO the GTK developers as they limit the GDK
  > Wayland backend to the protocols that want and not what someone behind
  > their horizon want.

That statement is so vague that I can't begin to tell what it means or
what it implies.  It might be an important issue, but you have not
said enough to make that visible.

Could you please describe in concrete terms the practical problems for
users that result from this?

If this makes Emacs support for Wayland difficult to write or
inconvenient to use, should we ask the developers of that backend to
ork with us on making it support Emacs better?

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