Problems embedding rxvt-unicode
Marc Lehmann
schmorp at schmorp.de
Sat Jul 17 13:30:30 CEST 2010
On Sat, Jul 17, 2010 at 11:25:38AM +0300, Tuukka Kataja <stuge at xor.fi> wrote:
> At least on my system (Ubuntu 10.04), xterm has a switch "-into" that
> works like "-embed" on rxvt-unicode.
I am intrigued, but I just looked at xterm sources, and see no traces of
xembed support. At all. As such, the -into option has nothing whatsoever
to do with -embed. (Which is consistent with the documentation of both
-into and -embed).
Since you claim otherwise, how do you come to the conclusion that it works
like -embed?
> I'm under the impression that scrotwm (being a window manager) doesn't
> have to support XEmbed.
Indeed, but bear with me - we are trying to disentangle your exact setup
form your mails, and you send a lot of conflicting statements.
> XEmbed is a protocol between only the embedding application
> (suckless.org's tabbed) and the embedded application (rxvt-unicode), is
> it not?
Right!
> Because of the XEmbed specification, which implies this in a couple of
> places:
I can't find it anywhere in the xembed specificaiton, and none of the parts
you quoted it mention it either.
> 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.
and rxvt-unicode fully handles XEMBED_MAPPED (which is not MapNotify).
> in the embedding application. (Map requests are also redirected, but
> XEmbed actually handles map requests separately... see the description of
> the XEMBED_MAPPED flag.)"
And rxvt-unicode doesn't rely on map requests, but instead uses
XEMBED_MAPPED.
> 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
Your mind works very strangely, as MapNotify isn't mentioned at
all. Moreso, map notifications in general are not handled by xembed at
all, and not mentioned at all. If you disagree, where in the xembed spec
does it handle map notifications?
> SubstructureRedirectMask. Therefore (if I understand X correctly)
> MapNotify events won't come to the embedded window unless the embedder
> specifically sends it them.
You don't understand X correctly - MapNotify is an event sent when the
window is mapped (and the window selects for it). It doesn't matter *how*
the window is being mapped.
> And the XEmbed spec doesn't require this, but
The Xembed spec doesn't require support for keyboard events either. The
xembed spec is about embedding, not about basic X functions - all the X
functionality is still there EXCEPT when it disagrees with the xembed
specification.
Or to put it otherwise: where in the xembed spec does it mention
XCreateWindow? If it doesn't mention it, how does one create windows?
Obviously, xembed does not invalidate the remaining parts of X.
> gives it's own method. Similar things are said in the spec for
> XEMBED_WINDOW_ACTIVATE and XEMBED_EMBEDDED_NOTIFY.
Note the absence of XEMBED_WINDOW_MAPPED or something like it.
> 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.
I think it is much preferable to get embedders (or WMs) right instead of
implementing hack workarounds for each and every application out there.
> 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
It would be possible that "tabbed" does something different when it is
running under scrotwm, than when it is running under gnome.
> But I still think the absence of MapNotify events shouldn't matter to
> rxvt-unicode when it's embedded.
Replace MapNotify with KeyEvent - is it still true for you? Why should
applications cope with partial breakage? Wouldn't it be better to do
it the right way, so not every embedding app needs to deal with broken
embedders?
> > 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.
It wasn't clear to me how your setup works (it still isn't, but it seems
clearer to me). Indeed, the wm isn't responsible here.
And the more I think about it, I think that your whole description of whta
happens is likely wrong - I would really expect the mapnotify to be sent.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp at schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
More information about the rxvt-unicode
mailing list