Re: embedding gtk widgets in a buffer

[joakim@verona.se]

Richard M Stallman <rms@gnu.org> 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