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?