> > Hi, how do you embed xterm? I didn't know xterm supported Xembed (but it > might). Are you sure scrotwm is actually supporting xembed? >
At least on my system (Ubuntu 10.04), xterm has a switch "-into" that works like "-embed" on rxvt-unicode. I'm under the impression that scrotwm (being a window manager) doesn't have to support XEmbed. XEmbed is a protocol between only the embedding application (suckless.org's tabbed) and the embedded application (rxvt-unicode), is it not? >> I've traced the problem to rxvt-unicode not receiving a MapNotify event >> when being embedded under scrotwm. Therefore, the "mapped" member of >> TermWin_t isn't set to 1 (although the windows are in fact mapped in X) >> and therefore no screen updates occur. >> >> Do correct me if I'm wrong, but I'm not sure that rxvt-unicode should >> expect to get MapNotify events when being embedded. > > Why not? MapNotify is a badic function of the X protocol - if scrotwm > override-redirects embedded windows and keeps vital events from them, then > it's broken. > Because of the XEmbed specification, which implies this in a couple of places: http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#lifecycle says under XEMBED_MAPPED: "If set the client should be mapped. The embedder must track the flags field by selecting for PropertyNotify events on the client and map and unmap the client appropriately. (The embedder can leave the client unmapped when this bit is set, but should immediately unmap the client upon detecting that the bit has been unset.) Rationale: the reason for using this bit rather than MapRequest events is so that the client can reliably control it's map state before the inception of the protocol without worry that the client window will become visible as a child of the root window. " This to me says: The embedder takes care of mapping/unmapping embedded windows and the embedded clients can ask for this to happen through XEMBED_MAPPED. Also, earlier in http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#rationale "The embedder selects with SubstructureRedirectMask on its window so that it can intercept, and then the client window is reparented (using XReparentWindow()) as a child of the embedder window. Because of the substructure redirect, the embedder is able to intercept calls to move or resize the client window, and handle them as appropriate to the location in the embedding application. (Map requests are also redirected, but XEmbed actually handles map requests separately... see the description of the XEMBED_MAPPED flag.)" Note the sentence in parenthesis. All of this indicates in my mind that expecting MapNotify events while being embedded isn't a good idea. After all, the XEmbed spec instructs the embedder to select the SubstructureRedirectMask. Therefore (if I understand X correctly) MapNotify events won't come to the embedded window unless the embedder specifically sends it them. And the XEmbed spec doesn't require this, but gives it's own method. Similar things are said in the spec for XEMBED_WINDOW_ACTIVATE and XEMBED_EMBEDDED_NOTIFY. Also, the fact that rxvt-unicode is getting VisibilityNotify events (with VisibilityUnobscured or VisibilityPartiallyObscured) should tell rxvt-unicode that it's windows are in fact mapped and visible, and therefore screen updates are required. All that said, I still can't figure out why the MapNotify events come through in GNOME but not in scrotwm. I checked, and scrotwm isn't seeing _any_ events from the embedded rxvt-unicode window, as it shouldn't because it's not a toplevel window. As far as I can tell, scrotwm isn't even aware of the embedded rxvt-window, so I can't see how it could mess things up for rxvt-unicode. Also, the flags scrotwm gives to XSelectInput for toplevels (like the suckless tabbed) are EnterWindowMask | FocusChangeMask | PropertyChangeMask | StructureNotifyMask so that shouldn't cause problems either (correct me if I'm wrong). But I still think the absence of MapNotify events shouldn't matter to rxvt-unicode when it's embedded. >> Maybe someone with more knowledge on Xlib could enlighten me (I'm >> familiar >> with the scrotwm source so I can go poking there if this is really >> scrotwm's fault). > > If rxvt-unicode calls mapwindow, and the wm makes it visible, then > rxvt-unicode is entitled to know about that. > When rxvt-unicode is being embedded, the WM isn't making it visible, because non-toplevel windows aren't the WM's problem. _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
