From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Running with both PGTK and an X toolkit? Date: Sat, 11 Mar 2023 10:04:07 +0200 Message-ID: <83edpvyars.fsf@gnu.org> References: <87pm9ghg28.fsf@catern.com> <87y1o4f9z1.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26001"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 11 09:05:16 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pauE8-0006Wi-4r for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 11 Mar 2023 09:05:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pauDM-0006J6-TR; Sat, 11 Mar 2023 03:04:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pauDH-0006IE-GA for help-gnu-emacs@gnu.org; Sat, 11 Mar 2023 03:04:27 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pauDH-0006K8-7z for help-gnu-emacs@gnu.org; Sat, 11 Mar 2023 03:04:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fQhCOkfgvRkh4iwC8HidDMjfzacI7JEufSg0FFgFofc=; b=jvuc+U1Yl+RD 9oZWBQ/VSwe5BGuaUQ3KFX6CrZLp4DAqSLcuPRn/Wj0EPi6CIy4HTyQXoT//yXFyqtE49GOV92rVR nljgDSPsTjNV8K+m+jSSeHu/0oNjjG6Ly47Jsepdq1BZOYlAvkCXIqa32HA86pDDR8tIIhKN683Lh kj+s2cOHnibNOWuj6Y5VtQQ5jP4bE7EkukRckoxN8drNlvuwfAh1iqGvGEgAmKdS9ANqoi2ZUmtB1 5DgMPM8JiJO+Kw7MsHBQfh/1FJTkqTj+cwk9KAHu7Zp5JW1viiyUqMoGxixob8g308QFbsG+kSTqo WOtivNlsm5exwtBvcqwKmA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pauDF-0007un-Vl for help-gnu-emacs@gnu.org; Sat, 11 Mar 2023 03:04:22 -0500 In-Reply-To: <87y1o4f9z1.fsf@yahoo.com> (message from Po Lu on Sat, 11 Mar 2023 07:44:02 +0800) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142979 Archived-At: [This discussion doesn't belong here, it belongs on emacs-devel.] > From: Po Lu > 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.