Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!cs.umn.edu!kksys!pwcs!com50!pai!erc From: erc@pai.UUCP (Eric F. Johnson) Newsgroups: comp.windows.x Subject: Re: Which window manager is up? Summary: Sometimes WM-specific code is OK Message-ID: <1817@pai.UUCP> Date: 26 Jun 91 14:13:12 GMT References: <9106210623.AA06713@lightning.McRCIM.McGill.EDU> Organization: Boulware Technologies, Inc., Burnsville, MN Lines: 89 In article <9106210623.AA06713@lightning.McRCIM.McGill.EDU>, mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: > > Does anybody know how to tell which window manager is running? > > You can't tell. You can't even tell *whether* a window manager is > running, at least not reliably. > > > For Motif there is a XmIsMwmRunning function, but what about twm? > > tvtwm? olwm? > > Some or all of those may provide some way to guess whether the WM is > running or not, but any such way can make mistakes (I feel sure > XmIsMwmRunning, for example, can be fooled). > > Why do you care? You shouldn't care what window manager is running; if > you think you do you are probably trying to solve the wrong problem. > > der Mouse > > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu I guess I'm trying to solve the wrong problem :-) (Actually, I don't care which window manager is running, but I do write WM-specific code, to make sure my applications look and work right under various window managers.) There seems to be a great myth that *all* users actually configure their systems and *choose* to use a particular window manager. In reality, many users *do* like to configure their X environment, but a great many don't even have a clue about configuring--nor do they want to. And, with window managers, there are really just a few that virtually everyone uses (including mwm, olwm and twm). Most users, I suspect, use the "default" window manager for their system. There really isn't a lot of choice: either be satisfied with the window manager(s) you have or write your own. Tom LaStrange writes his own. Joe and Jane User don't. As a real example (although it is perhaps extreme), the company I work for puts UNIX boxes (and other systems) into factories. Our users may know a lot about making little rubber rings or other products, but few know anything about UNIX, DOS or X. X to us is a means to provide a graphical interface, one that just happens to work on every UNIX box we support. This may sound like an extreme example, but as more and more people migrate to X, less and less will be willing to mess with the standard means for configuring X: resource files and start-up scripts. The bottom line is that I want our software to run reasonably well under *all* window managers, especially all that our users use. I'm willing to break any "rules" necessary to do just that. (Not that I have to break many rules--this is just my pragmatic philosophy.) This means that our code uses the standard ICCCM means of telling the window manager about our application (mostly writing to ICCCM-defined properties [%]). We also write to properties specific to particular window managers, such as _OL_WIN_ATTR (olwm) and _MOTIF_WM_HINTS (mwm), because we want greater control over the "environment" in which our program runs. (We write to the olwm and mwm properties all the time, since it is more hassle than it's worth to try to determine which window manager is running--if it is even possible to do so reliably.) Maybe, in trying to make our software work with a minimum of glitches, we are trying to solve the wrong problem. My end goal is software that works, where "works" is usually defined by our customers. > der Mouse > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu [%] (To use a der Mouse-style footnote) Not all window managers follow the ICCCM the same way. A specific example is mwm, which treats WM_SAVE_YOURSELF more like WM_DELETE_WINDOW ("die, sucker") than as a check- point facility (see 5.2 in the ICCCM--not implying the ICCCM is crystal clear), at least in the versions of mwm that I have here. Have fun, -Eric -- Eric F. Johnson BTI: Industrial Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems 415 W. Travelers Trail email: erc@pai.mn.org and services Burnsville, MN 55337 USA