Running with both PGTK and an X toolkit?

Running with both PGTK and an X toolkit?

[Spencer Baugh]

I'd like to configure an Emacs with both PGTK (for Wayland and Broadway)
and an X toolkit (for X - probably Lucid).  The reason is that I'd like
to simultaneously have X frames open and Wayland/Broadway frames open.

(More specifically, I think it would be cool to be able to use Broadway
to connect to my Emacs remotely through a web browser, but I use X for
my normal Emacs setup.)

Is it possible to have both PGTK and an X toolkit configured into Emacs?
I'm willing to do development work to make this work, if it's not
categorically impossible.

And if that is possible, is it possible to have two frames using two
different windowing systems at the same time?  (I feel like I've heard
about people doing that before, at least for other combinations)

Re: Running with both PGTK and an X toolkit?

[Po Lu]

Spencer Baugh <sbaugh@catern.com> writes:

> I'd like to configure an Emacs with both PGTK (for Wayland and Broadway)
> and an X toolkit (for X - probably Lucid).  The reason is that I'd like
> to simultaneously have X frames open and Wayland/Broadway frames open.
>
> (More specifically, I think it would be cool to be able to use Broadway
> to connect to my Emacs remotely through a web browser, but I use X for
> my normal Emacs setup.)
>
> Is it possible to have both PGTK and an X toolkit configured into Emacs?
> I'm willing to do development work to make this work, if it's not
> categorically impossible.
>
> And if that is possible, is it possible to have two frames using two
> different windowing systems at the same time?  (I feel like I've heard
> about people doing that before, at least for other combinations)

It is going to be very difficult to use those two window systems at the
time, but not impossible, unlike running the NS port along with other
window systems in the same process, where the very different event
handling systems make it impossible to design a `select' that works
reliably with both.

The problem here is that most of our code assumes that only one window
system has been built into Emacs: FRAME_WINDOW_P, the Fx_* functions in
each TERMfns.c file, ifdefs in xdisp.c and menu.c,
Fmenu_or_popup_active_p, et cetera.

So you will have to make all of those (the list I gave is nowhere near
exhaustive) aware of more than one window system; this probably means
moving the Fx_* functions out of each terminal's fns.[cm] file and
making them dispatch to the right function based on the frame's window
system, and tediously examining every other window system test to
determine what to do.

We also have a big Display_Info typedef that is always the current
window system's Display_Info structure.  Either each window system's
Display_Info structure will have to be made the same, or x*.c must stop
directly accessing display information.

Re: Running with both PGTK and an X toolkit?

[Spencer Baugh]

Po Lu <luangruo@yahoo.com> writes:
> Spencer Baugh <sbaugh@catern.com> writes:
>> I'd like to configure an Emacs with both PGTK (for Wayland and Broadway)
>> and an X toolkit (for X - probably Lucid).  The reason is that I'd like
>> to simultaneously have X frames open and Wayland/Broadway frames open.
>>
>> (More specifically, I think it would be cool to be able to use Broadway
>> to connect to my Emacs remotely through a web browser, but I use X for
>> my normal Emacs setup.)
>>
>> Is it possible to have both PGTK and an X toolkit configured into Emacs?
>> I'm willing to do development work to make this work, if it's not
>> categorically impossible.
>>
>> And if that is possible, is it possible to have two frames using two
>> different windowing systems at the same time?  (I feel like I've heard
>> about people doing that before, at least for other combinations)
>
> It is going to be very difficult to use those two window systems at the
> time, but not impossible, unlike running the NS port along with other
> window systems in the same process, where the very different event
> handling systems make it impossible to design a `select' that works
> reliably with both.
>
> The problem here is that most of our code assumes that only one window
> system has been built into Emacs: FRAME_WINDOW_P, the Fx_* functions in
> each TERMfns.c file, ifdefs in xdisp.c and menu.c,
> Fmenu_or_popup_active_p, et cetera.
>
> So you will have to make all of those (the list I gave is nowhere near
> exhaustive) aware of more than one window system; this probably means
> moving the Fx_* functions out of each terminal's fns.[cm] file and
> making them dispatch to the right function based on the frame's window
> system, and tediously examining every other window system test to
> determine what to do.
>
> We also have a big Display_Info typedef that is always the current
> window system's Display_Info structure.  Either each window system's
> Display_Info structure will have to be made the same, or x*.c must stop
> directly accessing display information.

OK, interesting.  From looking at it, it seems like probably I won't
need *too* deep of an understanding to deal with most of it - it's
mostly a lot of toil.  It seems like it's something I could do.

Is this a change which would be interesting to upstream?  I'm hesitant
to embark on it if not...

Also, are there any smaller component changes which would be interesting
upstream?

Re: Running with both PGTK and an X toolkit?

[Po Lu]

Spencer Baugh <sbaugh@catern.com> writes:

> OK, interesting.  From looking at it, it seems like probably I won't
> need *too* deep of an understanding to deal with most of it - it's
> mostly a lot of toil.  It seems like it's something I could do.
>
> Is this a change which would be interesting to upstream?  I'm hesitant
> to embark on it if not...

Yes, we are very interested in such a change.

> Also, are there any smaller component changes which would be interesting
> upstream?

No, not really.  Thanks for your interest in Emacs.  BTW, it might be
prudent for you to sign copyright papers now; email emacs-devel@gnu.org
for more details.

Re: Running with both PGTK and an X toolkit?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Sat, 11 Mar 2023 09:21:06 +0800
> 
> Spencer Baugh <sbaugh@catern.com> writes:
> 
> > Also, are there any smaller component changes which would be interesting
> > upstream?
> 
> No, not really.

I disagree about this part, see my other message.

> BTW, it might be prudent for you to sign copyright papers now; email
> emacs-devel@gnu.org for more details.

Right.

Re: Running with both PGTK and an X toolkit?

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@catern.com>
> Date: Sat, 11 Mar 2023 00:47:55 +0000 (UTC)
> Cc: help-gnu-emacs@gnu.org
> 
> Is this a change which would be interesting to upstream?  I'm hesitant
> to embark on it if not...

Yes, we are definitely interested.

> Also, are there any smaller component changes which would be interesting
> upstream?

Yes, these changes can be made piecemeal.  We already did similar
changes in the past, like converting the x_*, w32_*, and ns_*
functions into platform-independent gui_* functions.  The trick is to
make this safely, because there's a possibility of never reaching the
end goal, due to Life(TM) or whatever, and so too deep changes that
increase complexity but are not taken to their projected goal are a
burden we should avoid.  Small changes, which make it easier to
parameterize the implicit window-system dependencies and make them
explicit, and thus move us towards the goal, without introducing
unneeded complexities, is the way to go.

Re: Running with both PGTK and an X toolkit?

[Eli Zaretskii]

[This discussion doesn't belong here, it belongs on emacs-devel.]

> From: Po Lu <luangruo@yahoo.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Sat, 11 Mar 2023 07:44:02 +0800
> 
> It is going to be very difficult to use those two window systems at the
> time, but not impossible, unlike running the NS port along with other
> window systems in the same process, where the very different event
> handling systems make it impossible to design a `select' that works
> reliably with both.

Same with the MS-Windows frames.

So I think this kind of mixing is only possible on GNU and Unix
systems, where the same 'select' (or similar) call can handle several
"window systems".

> The problem here is that most of our code assumes that only one window
> system has been built into Emacs: FRAME_WINDOW_P, the Fx_* functions in
> each TERMfns.c file, ifdefs in xdisp.c and menu.c,
> Fmenu_or_popup_active_p, et cetera.

That is true, but the real problem is only in name clashes, I think.
Most, if not all, of the actual interfaces are called through
dispatches that accept the frame or its terminal object as an
argument, so it should be easy to make them call the correct
implementation.

> We also have a big Display_Info typedef that is always the current
> window system's Display_Info structure.  Either each window system's
> Display_Info structure will have to be made the same, or x*.c must stop
> directly accessing display information.

Yes, Display_Info variables will need to become function calls that
return a public portable structure, not something that is defined
differently for each window-system.