>> 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 came to the conclusion, because "tabbed" acted visually and functionally as though xterm had support for XEmbed. I can start multiple xterms with "-into" and they appear to "tabbed" exactly as should and behave normally. I didn't have the xterm sources at hand, so I wasn't able to check the implementation. From the man page I assumed (wrongly apparently), that "This is used to embed xterm within other applications" ment using XEmbed. Sorry. >> 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. > Please, see the end of the message for an attempt to clarify. >> 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. > I stand corrected. >> 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. > I agree. Using VisibilityNotify events was based on my misunderstandings of X. >> 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. > Tabbed is a very simplistic piece software, and doesn't care about the WM. This I have confirmed by tracking the execution of tabbed. Also, the same things happen using the example embedders. >> 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? > Again, I stand corrected.. >> > 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. > Let's see if I can clear things up a bit. I'm running Ubuntu 10.04. I'm able to log in either starting GNOME (Metacity I gather as the WM) or without GNOME using scrotwm as the WM. I'm trying to use "tabbed" to have a tabbed interface to rxvt-unicode. Yes, I know about the perl-extension, but this started as a test to see how to embed rxvt-unicode (planning to do it in a project of mine). Now, when I am logged in to a GNOME session everything works fine. When I log to a scrotwm session, rxvt-unicode works fine when not embedded. But when I attempt to embed rxvt-unicode with "-embed" no text is output, but the terminal works (which I can see from the scrollbar and blindly entered commands). This happens regardless of whether I'm embedding into "tabbed" or to the examples in rxvt-unicode's doc/-directory. I started investigating what was happening, and determined (using a primitive technique of fprintf's to stderr) that a MapNotify event is never being received by rxvt-unicode and therefore the screen isn't being updated. In the gnome session, the MapNotify _is_ received. If there is something that I'm missing which makes this conclusions wrong, do tell me. I just want to get the embedding to work, regardless of what piece of software is acting up. - Tuukka _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
