Andy> At 05:04 PM 8/20/99 +0900, SL Baur wrote: Andy> Now I understand what you mean this is not quite Andy> correct. Tabs are context sensitive. I.e. by default you Andy> will only see other tabs that relate to the buffer you are Andy> currently in. BTW, This is currently defined as "same mode" by default, right? BTW #2. I don't like the way new tabs always get added at the left. I assume by changing the `buffers-tab-selection-function' I can add them at the right? Or alphabetize them if I want? I am not an experienced X programmer, but there seem to be some strange things in the subwindow/widget implementation. First, it looks like the order of XMoveWindow and XMapWindow in the IMAGE_SUBWINDOW branch of x_map_subwindow() in src/glyphs-x.c is wrong (or maybe it doesn't matter?); the XMoveWindow call should come first, otherwise you're asking for flicker. The widget version immediately below looks right. (I presume it's the widget version that gets called for tab controls, so that can't be the problem here.) Second, the (new) function redisplay_unmap_subwindows_except_us() in src/redisplay-output.c seems like it would be the source of all flicker problems. Under X11, you don't want to iterate over the subwindows; you just unmap the window of interest (the tab control widget). This makes all of its subwindows invisible, and the server should stop generating any Expose events (modulo network lag). But if you don't unmap that window, it will keep receiving Expose events as you map and unmap the subwindows (individual tabs, here). Unless you are very careful about throwing away expose events that occur in the top window (tab control widget), you're going to get extreme amounts of flicker. So that function seems to be exactly backwards. What is the child widget in the tab control? Is there one? If the XEmacs text window is reparented to be a child of the tab control widget, the unmap the whole tab widget strategy doesn't work, but that doesn't seem like the right thing to do. Third, as I understand the code, the subwindow of XEmacs seems to be the tab widget itself. But this is probably too direct. For example, the code contains a comment that if the whole subwindow can't be viewed, none of it should be viewable. I don't think that's right; I can easily think of several applications where you might want it to be partially visible. Also, I don't see why XEmacs shouldn't be able to "swallow" (to use the Fvwm term) X windows created by other processes. One (naive) way to help accomplish both of these goals would be to have the subwindow itself be a "shell" window (like window managers use); then overlay the widget on that or reparent the toplevel window of the external process. X11 puts no constraint that the subwindow be smaller than the "shell", but it won't let the subwindow write outside of the "shell". Viola! correct clipping. Of course, as is pointed out in the comments to the new code, there are all kinds of un-XEmacsy aspects here. Eg, you can't put a subwindow glyph into a buffer, really; it has to be part of the frame. It's not clear how you would handle multiple instances of a fractal-plotting program swallowed into an XEmacs buffer, for example. (It probably _could_ be done, but that would be a wizardly hack!) But that's life, I guess---we accept the restriction. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."

At 01:48 PM 8/23/99 +0900, Stephen J. Turnbull wrote: Yes. The order is generally dictated by the order of buffer-list which is LRU. If you add any funky configuration possibilities please submit them and I'll put them in. Alphabetical is a good candidate. Correct. The SUBWINDOW stuff is not really used at the moment although it does work as Jan verified. Well I have no control over the unmapping and mapping of individual tabs - that is handled by the Tab Widget itself. The window we are unmapping *is* the top level one so that should be ok. The *except_us function is to avoid unmapping the widget at all if possible. So I'm not convinced this is the problem. In fact I'm still pretty convinced that the expose events are for the widget being *unmapped* rather than mapped. XmLabels or Xaw labels. No, I don't think it is the right thing. This is an X problem. You have to remember that the subwindow/widget implementation is generic, it allows subwindows/widgets to be displayed in buffers as well as the gutter area. The problem is that I can find no way of clipping widgets except with other widgets or the edge of a frame. This is no good for the bottom of the gutter say or the area just above the modeline. In both cases you need a clipped widget without anything to clip it with. Hence unmapping everything seems the only solution. I tried relaxing this restriction if I knew the widget was at the edge of the frame but that caused more expose problems. Oo-er missus. That's not a bad idea. Kind of complicated though. I'll ponder it some more and may give it a hack when I have some more time. I'm currently redoing a lot of the redisplay code for pixmaps/subwindows etc and have fixed quite a few redisplay problems with subwindows. Do you mean instantiated instances are per-window? Yes that's a bummer but not so bad. You can even have multiple instances in the same buffer as long as they are not visible in the same window at the same time. I'm not too upset about it. Thanks for your comments. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

At 06:11 PM 8/23/99 +0900, Stephen J. Turnbull wrote: Andy> Did it flicker without this change? No. That platform (Gateway Solo 2000, C&T 65555, XF86_SVGA, Linux) flickered in the very early implementation (at the time of Steve Baur's first reports). Many things since then have changed, and I have observed no flicker since the early fixes. Since no expose events are generated while the glyph/subwindow is unmapped, that should reduce flicker in this case as I understand the theory. I can only say that on my platform it doesn't increase flicker, so it's worth a try. Andy> If it works for you then I'll put it in. Hmm. I managed to get a lot of flicker with this build today, by dragging one frame over another's tab control area. I also saw it when I created a new frame with C-x 5 b and it happened (Window Maker wm with RandomPlacement set) to partially obscure an existing frame's tab control area. I couldn't reproduce with an xterm over XEmacs, but that won't exercise XEmacs redisplay in the same way. It's intermittent but common with XEmacs frame over frame. Even when it doesn't flicker, the whole tab area disappears for a perceptible time. Not good if it can be avoided. Maybe it's not such a good idea. Window Maker is set to opaque drag, though, and this produces a "poor man's bold" effect in the dragged window, and a ripple of redisplay in the obscured one, it's such a bandwidth hog (and those effects _always_ happen). Andy> I don't understand. Execute src/xemacs -q src/*{glyphs,redisplay}*.[ch] & See that tabs are redisplay-msw.c and glyphs.h; buffers are redisplay.[ch] Now C-x 1 to redisplay.h; C-x 5 b glyphs.h Rearrange the frames to overlap: ------------------------------------------------------------------------ ------------------------------------------------------------------------ Frame 2 tabs are redisplay-{output,msw}.c Click frame 2 to redisplay-msw.c. Frame 2 tabs are glyphs.h redisplay.h redisplay.c redisplay-x.c redisplay-tty.c ------------------------------------------------------------------------ ------------------------------------------------------------------------ Raise frame 1 over frame 2, then raise frame 2. Now frame 2 tabs are redisplay-{tty,output}.c ------------------------------------------------------------------------ ------------------------------------------------------------------------ Perfectly reproducible, so I can't call it random. "Chaos", anyone? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."

At 01:49 PM 8/24/99 +0900, Stephen J. Turnbull wrote: Its not the subwindow receiving the expose event - its the XEmacs frame for the exposed area which causes redisplay to redisplay and so on.... This won't affect flashing though. I've told ed about the tab build problems, hopefully he will be able to figure something out. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd