kochhar@babbage.harvard.edu (Sandeep Kochhar) (02/13/90)
Hi! Here's my question: According to the ICCCM, the toplevel window of an application should set it's colormap, but not *install* it, since the windowmanager will do that. However, if there's no window manager running, will the colormap still get installed by, say, the server? If not, what's the simplest way to be able to handle the no windowmanager case, and yet be ICCCM-compatible? Thanks Sandeep Kochhar (617) 495-3988 mail: kochhar@harvard.harvard.edu Harvard University kochhar@harvard.csnet 33 Oxford st, kochhar@harvard.uucp Cambridge, MA 02138 kochhar@harvard.bitnet Fax: (617) 495-9837
msm@src.dec.com (Mark S. Manasse) (02/13/90)
Regrettably, the ICCCM team was unable to find any way for clients to reasonably make colormaps work in the absence of a window manager, due to unsolvable race conditions in the protocol with regard to colormaps. You could make some sort of half-hearted attempt to determine whether a window manager was running (say, by attempting to select for SubstructureRedirect on the root window, and then deselecting), but it would be wrong. As a client programmer, you should therefore assume that there will be a window manager running. There may be transient states in which there isn't, but colormap installation shouldn't be a major concern at such times. Mark
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/13/90)
> Here's my question: According to the ICCCM, the toplevel window of an > application should set it's colormap, but not *install* it, since the > windowmanager will do that. More precisely, it's the window manager's job to do that if-&-when its policy says it should be done. Nothing says it will ever actually happen. > However, if there's no window manager running, will the colormap > still get installed by, say, the server? Almost certainly not (though as I understand it, the server would be free to use anything it likes as the colormap if the required list is empty, which I believe it will be when nobdy has called XInstallColormap yet). > If not, what's the simplest way to be able to handle the no > windowmanager case, and yet be ICCCM-compatible? What I recommend (and use in my programs) is to provide an option the user can use which means that there's no window manager running (or at least if there is it doesn't handle window colormaps correctly), and that the program should call XInstallColormap and XUninstallColormap itself at appropriate times (typically on EnterNotify and LeaveNotify events). There are doubtless other reasonable approaches; I don't suppose it really makes much difference which one you pick. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
kochhar@HARVARD.HARVARD.EDU (02/13/90)
> >What I recommend (and use in my programs) is to provide an option the >user can use which means that there's no window manager running (or at >least if there is it doesn't handle window colormaps correctly), and >that the program should call XInstallColormap and XUninstallColormap >itself at appropriate times (typically on EnterNotify and LeaveNotify >events). There are doubtless other reasonable approaches; I don't >suppose it really makes much difference which one you pick. > > der Mouse > > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu Thanks for your reply. I was also wondering; instead of having the user specify that no window manager is running, is there a way for the application to automatically detect that? For example, twm seems to be able to detect that another window manager is already running; I haven't been able to figure out how it does that---do you know how it might do that? Thanks Sandeep Kochhar (617) 495-3988 mail: kochhar@harvard.harvard.edu Harvard University kochhar@harvard.csnet 33 Oxford st, kochhar@harvard.uucp Cambridge, MA 02138 kochhar@harvard.bitnet
baur@venice.SEDD.TRW.COM (Steven L. Baur) (02/14/90)
From article <9002130408.AA13069@ATHENA.MIT.EDU>, by kochhar@HARVARD.HARVARD.EDU: > ... I was also wondering; instead of having > the user specify that no window manager is running, is there a > way for the application to automatically detect that? For example, > twm seems to be able to detect that another window manager is > already running; Twm detects another window manager when calling XSelectInput on the root window. If this call fails, it assumes that another wm is there. (Only one client is allowed to select button press events on a window). Olwm does this too. Here is the code: (twm) RedirectError = FALSE; XSetErrorHandler(CatchRedirectError); XSelectInput(dpy, RootWindow (dpy, scrnum), ColormapChangeMask | EnterWindowMask | PropertyChangeMask | SubstructureRedirectMask | KeyPressMask | ButtonPressMask | ButtonReleaseMask | ExposureMask); XSync(dpy, 0); XSetErrorHandler(TwmErrorHandler); (olwm) ErrorSensitive("Perhaps there is another window manager running?"); XSelectInput( DefDpy, RootWindow(DefDpy, DefScreen), KeyPressMask | SubstructureRedirectMask | ButtonPressMask | ButtonReleaseMask | Button1MotionMask | Button2MotionMask | EnterWindowMask ); XSync(DefDpy, False); ErrorInsensitive(DefDpy); -- steve baur@venice.SEDD.TRW.COM A computer which cannot run GNU emacs is not worth using.
toml@ninja.Solbourne.COM (Tom LaStrange) (02/14/90)
>> ... I was also wondering; instead of having >> the user specify that no window manager is running, is there a >> way for the application to automatically detect that? For example, >> twm seems to be able to detect that another window manager is >> already running; > >Twm detects another window manager when calling XSelectInput on the root >window. If this call fails, it assumes that another wm is there. (Only >one client is allowed to select button press events on a window). Almost. It's actually the SubstructureRedirectMask that only one client is allowed to do. While this will work most of the time to determine if a window manager is running, I don't think there's anyway to determine if the window manager goes away later. -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/15/90)
>>> ...is there a way for the application to automatically detect that? [that there is or isn't a window manager running] >> Twm detects another window manager when calling XSelectInput on the >> root window. If this call fails, it assumes that another wm is >> there. (Only one client is allowed to select button press events on >> a window). > Almost. It's actually the SubstructureRedirectMask that only one > client is allowed to do. Mostly true but nonetheless somewhat misleading. From the Xlib doc file in the R4 distribution: Multiple clients can select input on the same window. ... However, only one client at a time can select for SubstructureRedirectMask, ResizeRedirectMask, and ButtonPressMask. If a client attempts to select any of these event masks and some other client has already selected one, a BadAccess error results. So yes, substructure redirection can be selected for by only one client at a time, as you say. But, contrary to your implication, the same is true of button press events. As a side note, the last sentence I quoted from the doc file makes it sound as though selecting for any one of the three masks mentioned will prevent anyone else from selecting any of the three, even the other two. Is this really the way it works? Is this really the way it's supposed to work? If so, why? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mbr@aoa.UUCP (Mark Rosenthal) (02/16/90)
In article <9002151215.AA02926@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes:
)From the Xlib doc
)file in the R4 distribution:
)
) Multiple clients can select input on the same window. ...
) However, only one client at a time can select for
) SubstructureRedirectMask, ResizeRedirectMask, and
) ButtonPressMask. If a client attempts to select any of these
) event masks and some other client has already selected one, a
) BadAccess error results.
)
)So yes, substructure redirection can be selected for by only one client
)at a time, as you say. But, contrary to your implication, the same is
)true of button press events.
ButtonPressMask????? Does this mean that if I have 3 xterms and no window
manager running, only one xterm will respond properly to button presses?
That can't be right. Can it?
--
Mark of the Valley of Roses
...!bbn.com!aoa!mbrbaur@venice.SEDD.TRW.COM (Steven L. Baur) (02/16/90)
From article <1171@aoa.UUCP>, by mbr@aoa.UUCP (Mark Rosenthal): > > ButtonPressMask????? Does this mean that if I have 3 xterms and no window > manager running, only one xterm will respond properly to button presses? > That can't be right. Can it? It's not. Each of the 3 xterms has its own window, so there is no conflict. -- steve baur@venice.SEDD.TRW.COM A computer which cannot run GNU emacs is not worth using.
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/16/90)
>> From the Xlib doc file in the R4 distribution: >> Multiple clients can select input on the same window. ... >> However, only one client at a time can select for >> SubstructureRedirectMask, ResizeRedirectMask, and >> ButtonPressMask. If a client attempts to select any of these >> event masks and some other client has already selected one, a >> BadAccess error results. > ButtonPressMask????? Does this mean that if I have 3 xterms and no > window manager running, only one xterm will respond properly to > button presses? That can't be right. Can it? Fortunately that is not correct. The reason? Each xterm is selecting for ButtonPressMask on a different window. The whole paragraph I quoted is describing *per-window* restrictions. You can have many different clients selecting for ButtonPressMask, provided they are asking for button presses from different windows. (The same is presumably true of the redirect masks, but it's probably less useful in that case.) Thus, if the xterms were asking for ButtonPressMask on the root window, there would be a conflict. But in reality, each xterm is selecting for ButtonPressMask on is one of its own windows, so there's no problem. The window manager discussion hasn't mentioned this explicitly, because window managers almost have to ask for this sort of thing on the root. I admit the paragraph I quoted could be clearer on this point. (At least I didn't write it - it's not my fault :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
steve@acorn.co.uk (Steve "Daffy" Hunt) (02/27/90)
In article <9002151215.AA02926@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: >So yes, substructure redirection can be selected for by only one client >at a time, as you say. But, contrary to your implication, the same is >true of button press events. Sorry this followup is so far behind the thread! 1000 unread articles in comp.windows.x, I'm sure you all know the feeling. I believe the reason for using substructure redirect as the test for a window manager is that all window managers must (by definition!) have selected for this. This is not the case for the other masks mentioned; hence substructure redirect is the right choice for window manager detection. Sorry if this point is blindingly obvious, but I did not see it in any of the discussion. Steve Hunt
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (03/06/90)
>> So yes, substructure redirection can be selected for by only one >> client at a time, as you say. But, contrary to your implication, >> the same is true of button press events. > Sorry this followup is so far behind the thread! 1000 unread > articles in comp.windows.x, I'm sure you all know the feeling. Well, in my case it's 50 messages pending action in my mailbox, but the effect is much the same. > I believe the reason for using substructure redirect as the test for > a window manager is that all window managers must (by definition!) > have selected for this. Sez who? Not to sound argumentative or anything (:-), but I was thinking about it the other day and I realized that my window manager has no need to select for SubstructureRedirectMask. Its policy is to let windows do anything they want with respect to where and when they appear, how they resize or restack themselves, etc, so what does it need substructure redirection for? Nothing. > Sorry if this point is blindingly obvious, but I did not see it in > any of the discussion. I think its obviousness blinded you :-); I would have brought it up myself except that I think it's not true. (If there is some reason why a window manager *must* select for SubstructureRedirectMask on the root, I'd like to hear it.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu