From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: embedding gtk widgets in a buffer Date: Fri, 09 May 2008 01:13:58 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1210288703 31044 80.91.229.12 (8 May 2008 23:18:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2008 23:18:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 09 01:18:59 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JuFO6-0003zZ-Sc for ged-emacs-devel@m.gmane.org; Fri, 09 May 2008 01:18:59 +0200 Original-Received: from localhost ([127.0.0.1]:45905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuFNO-0000u2-LI for ged-emacs-devel@m.gmane.org; Thu, 08 May 2008 19:18:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JuFNK-0000tx-H6 for emacs-devel@gnu.org; Thu, 08 May 2008 19:18:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JuFNJ-0000tl-VO for emacs-devel@gnu.org; Thu, 08 May 2008 19:18:10 -0400 Original-Received: from [199.232.76.173] (port=54984 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuFNJ-0000ti-Q2 for emacs-devel@gnu.org; Thu, 08 May 2008 19:18:09 -0400 Original-Received: from iwfs.imcode.com ([82.115.149.64]:46725 helo=gate.verona.se) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JuFNH-0001DW-53; Thu, 08 May 2008 19:18:07 -0400 Original-Received: from chopper (IDENT:1005@localhost [127.0.0.1]) by gate.verona.se (8.13.4/8.11.4) with ESMTP id m48NI0Br011907; Fri, 9 May 2008 01:18:02 +0200 In-Reply-To: (Richard M. Stallman's message of "Thu, 08 May 2008 18:28:45 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:96834 Archived-At: Richard M Stallman writes: > - callback interface for the widgets. It would be nice with some ideas > how to do this. For instance: > - button pressed handler > > The natural way is for this to generate events, and when those events > reach the main loop, they will do whatever it is. Ok, I will look into this. does "whatever it is" include calling a callback I associate with the widget? > > - when a xembed widget is ready, a callback to start an external > program in the widget would be nice, now it has to be done manually on > the cmd line > > This callback does not need to be visible from Lisp. > When you create the widget, you specify the command and args > for the command to start the program. In the C code, > Emacs can handle the callback by starting it. Ok. I was thinking more along having the generic callback interface solve this too, and also that Id like to create the process in lisp, so I could bind a sentinel to it, and send commands to it through stdio, etc. > > - 2 windows showing the same buffer doesnt quite work and is probably tricky > > It would be a pain in the neck to have buffers that are not allowed to > appear in more than one window, but this may be necessary for the > xembed case. > > Buttons in the buffer ought to be able to work on more than one Emacs > window. > > The only way I can think of to make the xembed widgets work in more > than one Emacs window is if you can tell the other program to display > in a pixmap, and then Emacs redisplay would copy that pixmap to the > screen. Well, I wasnt planning on inhibiting the display of a buffer in more than one window. The problem is also the same for gtk_sockets, which implement xembed, and gtk_buttons etc. They can't appear in more then one place of the screen at the same time. (Or can they?) I thought of 2 solutions: - create new instances of the widgets for every window the widget is supposed to be shown. This is visualy appealing, but troublesome to implement, at least if each widget is really going to look like its counterpart in another window, especially for xembed. - the selected window and other windows are not drawn the same way. The selected window contains the real live widgets. The non-selected windows show some kind of shadow copy of the widget, in the simplest case a grey rectangle, more elaborately a bitmap copy of the widget at the time the window selection switch was made. I will implement the 2nd solution to begin with, since it seems simplest. -- Joakim Verona