dbeck@flopn2.csc.ti.COM (Dave Beck) (06/21/91)
Does anybody know how to tell which window manager is running? For Motif there is a XmIsMwmRunning function, but what about twm? tvtwm? olwm? Dave Beck Software Systems and Applications Lab Texas Instruments dbeck@flopn2.ti.com
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (06/21/91)
> 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
schoeller@clt.enet.dec.com (Dick Schoeller) (06/25/91)
In article <9106210623.AA06713@lightning.McRCIM.McGill.EDU>, mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: |> 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. ----- Sure, XmIsMotifWMRunning can be fooled. All you have to do is make your window manager do the same things mwm does. Checking for window manager running is less important now that most window managers are ICCCM compliant. As long as you aren't trying to do wm specific stuff, you shouldn't care. However, if you are expecting to run in an environment where a substantial number of users may be using a non-ICCCM window manager (ie: dxwm), then you may want to do some checking in order to determine which method to use for some operations such as iconification or changing the icon pixmap or using the iconify pixmap field in DEC_WM_HINTS. Dick Schoeller | schoeller@clt.enet.dec.com Digital Equipment Corporation | 603-881-2965 110 Spit Brook Rd., ZKO2-3/R56 | "Either Judaism has something to say to the Nashua, NH 03062-2642 | world or it has nothing to say to Jews." | - Dennis Prager
erc@pai.UUCP (Eric F. Johnson) (06/26/91)
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
mrs@warlock.Philips.Com (Mark R. Simpson) (06/29/91)
Why would an application programmer care which wndow manager
is running?
Well, I found the need to know when I wrote a program
using XVIEW that primarily ran under olwm. Unfortunately,
when users used mwm istead, some of the functionality
was lost.
Specifically, XVIEW's pushpin facility works under olwm
but not under mwm (or twm for taht matter).
The pushpin functionality is
easily mimiced (in fact, I created a pushpin type
functionality using sun's old sunview GUI).
Therefore, if olwm is running I use XVIEW's pushpin
facility, if another window manager is running I
call my own procedures that reproduce the pushpin
functionality. So teh question still remains, how
do you determine which window manager is running.
can
,stripes@eng.umd.edu (Joshua Osborne) (07/01/91)
In article <1991Jun28.190237.22565@philabs.philips.com> mrs@warlock.Philips.Com (Mark R. Simpson) writes: >Why would an application programmer care which wndow manager >is running? > >Well, I found the need to know when I wrote a program >using XVIEW that primarily ran under olwm. Unfortunately, >when users used mwm istead, some of the functionality >was lost. What happens when you make mwm send a ICCCM delete to a pinned menu, it goes away, right? It does when I make tvtwm do it. >Specifically, XVIEW's pushpin facility works under olwm > but not under mwm (or twm for taht matter). > The pushpin functionality is > easily mimiced (in fact, I created a pushpin type > functionality using sun's old sunview GUI). > >Therefore, if olwm is running I use XVIEW's pushpin >facility, if another window manager is running I >call my own procedures that reproduce the pushpin >functionality. So teh question still remains, how >do you determine which window manager is running. What if I make tvtwm understand (someof) the hints XView apps give olwm, will I get two push-pins? No real hardship, but it won't look too good. Look at the olwm source and see if it has any props that it attaches to the root window to identify itself (or just use xprop). However I would also (or only) make it controable by a resource "foo.WMNoPushPins: bool" so if a user has a WM that does push-pins but isn't olwm they don't get 2 push-pins. (who cares if 90% of your users can't read the docs, put it there, they sys-admin may read it if users complain, besides give the last 10%, the computer litterate ones a chance). -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)