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 06:11 PM 8/23/99 +0900, Stephen J. Turnbull wrote: Well I wrote most of the comments so I'm glad I agree with myself :) Did it flicker without this change? I still see some redisplay wierdness in my hacked version which has a lot of fixes in. The idea behind the change is that the window will just get moved rather than unmapped/mapped if humanely possible. Unfortunately redisplay bites us most of the time since it quite often clears the old area before drawing the new area. If it works for you then I'll put it in. There were no changes since then, so that's good. Hmmn, that's irritating. The widget should not be doing this. I'll see if I can force it off. I know about this. I haven't come up with a good solution yet. Your window in a window would help. There is no obvious hook to hang a frame size change off so really it should clip - which is problematic .... I don't understand. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

At 01:48 PM 8/24/99 +0900, Stephen J. Turnbull wrote: Ahh, ok I understand now. This works just fine under mswindows. The problem is the tab widget which is trying to display on multiple lines rather than one-long line as requested. This is similar to the grouping bug stef reported. I've asked Ed for a scrolling tab widget but I'm not sure whether or when he will do it. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

Andy> In fact I'm still pretty convinced that the expose events Andy> are for the widget being *unmapped* rather than mapped. In X11, an unmapped window can't receive events at all because it's invisible. If all of the descendents of the subwindow/glyph are mapped first, then the subwindow/glyph is mapped, it cannot step on its own toes (unless that causes its children to reconfigure themselves). I guess it's possible that since tabs are normally used in dialog boxes, the programmer got away with an implicit assumption that the tab control widget would always be on top, and wouldn't have to deal much with Expose events. I'm becoming rapidly convinced this is the way to go. I got a < 1 sec flash where I saw the tabs completely discombobulated, in no particular order, not in a row (maybe about three rows?) Can't reproduce, of course :-( -- 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."