[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Running with both PGTK and an X toolkit?

From: Spencer Baugh
Subject: Re: Running with both PGTK and an X toolkit?
Date: Sat, 11 Mar 2023 00:47:55 +0000 (UTC)

Po Lu <> writes:
> Spencer Baugh <> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]