Re: XEmacs has just (more than) doubled in size
At 01:48 PM 8/23/99 +0900, Stephen J. Turnbull wrote:
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?
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.
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.)
Correct. The SUBWINDOW stuff is not really used at the moment although it
does work as Jan verified.
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.
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.
What is the child widget in the tab control? Is there one? If the
XmLabels or Xaw labels.
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.
No, I don't think it is the right thing.
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.
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.
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.
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.
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!)
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.
But that's life, I guess---we accept the restriction.
I'm not too upset about it.
Thanks for your comments.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd