From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Timo Savola Newsgroups: gmane.emacs.devel Subject: Re: GtkPlug patch Date: Tue, 03 Jan 2006 22:29:44 +0200 Message-ID: <1136320184.7852.45.camel@localhost.localdomain> References: <200601030753.k037rc1o021950@coolsville.localdomain> <85d5j9f99e.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1136320217 19265 80.91.229.2 (3 Jan 2006 20:30:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2006 20:30:17 +0000 (UTC) Cc: "JanD." , rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 21:30:13 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Etsn2-0003El-AD for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2006 21:29:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtsoW-0000JT-5h for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2006 15:31:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Etso3-0000CO-1T for emacs-devel@gnu.org; Tue, 03 Jan 2006 15:30:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Etsns-00009X-Ej for emacs-devel@gnu.org; Tue, 03 Jan 2006 15:30:54 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Etsns-00009T-9C for emacs-devel@gnu.org; Tue, 03 Jan 2006 15:30:44 -0500 Original-Received: from [213.243.153.37] (helo=smtp1.pp.htv.fi) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Etsol-0002Yp-9G; Tue, 03 Jan 2006 15:31:39 -0500 Original-Received: from [192.168.1.104] (cs78235208.pp.htv.fi [62.78.235.208]) by smtp1.pp.htv.fi (Postfix) with ESMTP id 9A6CA7FC0E; Tue, 3 Jan 2006 22:28:07 +0200 (EET) Original-To: David Kastrup In-Reply-To: <85d5j9f99e.fsf@lola.goethe.zz> X-Mailer: Evolution 2.4.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:48676 Archived-At: > Question: would this stuff make any difference unless Emacs was called > in a special way? Is there some protocol advertising the possibility > for embedding that might be used by window managers or other > applications to check for embeddability? Emacs becomes embeddable only if parent-id is passed to a frame. A normally created frame's window doesn't get the _XEMBED_INFO property. (This is the "alternate method of beginning the protocol" mentioned in the "Embedding life cycle" section of the XEmbed spec.) > If all of this is not the case, then the respective code paths would > basically just get exercised when one explicitly does something that > one could not do before. If there are just a few such code spaces, > the impact on the general release quality would be negligible. I was thinking that perhaps the functionality could be implemented internally (emacs-gtkplug.patch, emacs-parent-fix.patch) even if the command-line interface change (emacs-parentid.patch) is too radical at this point. Is modifying the initial-frame-alist using --eval or some other means possible before the frame is created? Is it possible to use --batch to bootstrap and run the Emacs main loop? If so, embedders could set the parent-id manually while the XEmbed functionality is experimental. > How hard will it be to integrate those patches (or the respective > functionality) after the release? Would it make sense to integrate > them already in the multi-tty branch, or should we rather store them > somewhere separately after the release? Separate branch? The current patches are quite trivial. I guess a bigger question is: against which branch should the Xlib/Xt version be implemented? (A decentralized revision control system would help here.) > Does this make sense? Or would the authors of this patch prefer to > try their hand again from a clean head after release? I prefer to do what's best... timo