Problems embedding rxvt-unicode

[Tuukka Kataja]

>
> 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.