this doesnt actually work at all, but it does do some interesting things with composition, and contains lots of random experimental code. so i commit now, remove junk, and continue

1 files changed, 29 insertions, 21 deletions

diff --git a/README.xwidget b/README.xwidget
index 506e34a7866..e8617392ef5 100644
--- a/README.xwidget
+++ b/README.xwidget
@@ -18,19 +18,21 @@ buffer with a display spec. Also, xwidgets exists in only one copy,
 where a plain image can be shown in several windows. The xwidget code
 tries to handle this by essentialy making a screen capture of the
 widget and displaying those in the non-active windows, and the live
-widget in the active window. This doesnt currently work for xembed
-gtk_socket widgets.
+widget in the active window. The current snapshot code doesnt work if
+the live xwidget is off-screen. This seems to be solveable by using
+the XComposite interface, but that doesnt currently work.
 
 The current state is that one window, one frame, showing many xwidgets
 is a nice demo. One frame, many windows, will have lots of display
-glitches. Many frames, many windows, will probably work even worse.
+glitches. Many frames, many windows, will work even worse.
+
 
 * Brief overview of how xwidgets work
 Xwidgets work in one way like images in Emacs. You bind a display spec very
 similar to an image display spec to buffer contents. The display engine will
 notice the display spec and try to display the xwidget there. The display engine
 prepares space at the right place for the xwidget and so on for free, as long as
-we provide proper sizes and so on. 
+we provide proper sizes and so on back to the redisplay engine.
 
 The problem is that Emacs cant actually draw the widgets, as it can with
 images. Emacs must notify GTK about where the widgets should be, and how they
@@ -50,33 +52,34 @@ synchonous with Emacs display changes. Ok, so why is that difficult then?
   display is clever and optimized. It is often difficult to know that a xwdiget
   hasnt actually been displayed after a redisplay.
 
-- phantom views of xwidgets are thankfully not so hard because gtk supports
-  offscreen rendering of many widget types. Except it doesnt for the gtk socket
-  type, which happens to be very desirable. This might be solvable with
-  xcomposite, but is difficult.
+- phantom views of xwidgets are thankfully not so hard because gtk
+  supports snapshoting of many widget types. Snapshoting doesnt seem
+  to work if the live widget is offscreen. This might be solvable with
+  xcomposite, but attempts have so far failed.
 
-- The gtk socket type for embedding external applications is desirable but
-  presents a lot of difficulties of its own. Offscreen rendering has been
-  mentioned already. Another difficulty is deciding which input events to
-  forward, and when and how to do it. 
+- The gtk socket type for embedding external applications is desirable
+  but presents a lot of difficulties of its own. One difficulty is
+  deciding which input events to forward, and when and how to do it.
 
 - The case of showing an xwidget in several frames is not solved at all
   currently. This would mean moving the live xwidget between frames when the
   selected window moves. The gtk widget will need to be reparented between
-  windows, which seem fragile.
+  windows, which seems fragile. 
 
 * ToDo:s
 
-** TODO Examine using XComposite rather than GTK off-screen rendering. This
-  would make xembed widgets work much better. This would probably be
-  rathter difficult, but could open up other interesting possibilities
-  for Emacs.
+** TODO Examine using XComposite rather than GTK off-screen
+  rendering. This would make xembed widgets work much better. This
+  would probably be rathter difficult, but could open up other
+  interesting possibilities for Emacs. There is an early attempt in
+  xwidget.c, but the X call to redirect to offscreen rendering fails
+  for unknown reasons.
 
 ** TODO  make the keyboard event code propagation code work. There is an attempt 
 to provide an api to send keyboard events to an xwidget, but it doesnt currently
 work very well.
 
-** TODO  remove the special-case for when the minibuffer is
+** DONE remove the special-case for when the minibuffer is
   active.  I added some code to reduce the annoying problem display artefacts
   when making the minibuffer the selected window. This made xwidgets in the
   buffer go grey or black whenever one did m-x to activate the minibuffer. The
@@ -84,15 +87,18 @@ work very well.
   good idea. Special-casing will never work properly. It is much better to spend
   time finding solutions that work acceptably in the general case.
 
-** TODO  disable emacs cursor drawing on top of an active xwidget. 
+** DONE disable emacs cursor drawing on top of an active xwidget. 
   This ought to be rather simple and should improve the visuals a lot.
+  
 
 ** TODO  figure out what to do with the multiple frames case. 
 I havent spent any time at all on this.
 
 ** TODO  improve the xwidgets programming interface so its less of
   hand-waving affair. This shouldnt be too hard, but I have deliberatley not
-spent any time on it, since getting the visuals right is much harder.
+spent any time on it, since getting the visuals right is much
+harder. Anyway, I sort of think the interface should be somewhat like
+it is, except symbols is used instead of integers.
 
 ** TODO  more documentation
 There should be user docs, and xwidget contributor docs. The current README
@@ -102,5 +108,7 @@ is all contributor docs there is now, apart from the code.
 window rather than a point in a buffer. This was suggested by Chidong.
 This would be a useful addition to Emacs in itself, and would avoid nearly all 
 display issues. I still think the general case is more interesting, but this
-special case should also be added.
+special case should also be added. The xwidget would then be bound to
+replace the view of a particular window, and it would only show in
+that window.