arne@yc.estec.nl (Arne Lundberg) (02/14/90)
I am using HP OSF/Motif on a HP 9000/800 system. I have been using twm for some time and does not plan to switch over to mwm that is part of Motif. This gives me create a couple of problems when I am writing a Motif based application. 1) The manual specifies that Dialogs should always be iconified together with the toplevel window for the application. This does not work when using R4 twm but (of course) when I use the Motif windowmanager mwm. 2) To get a modal dialog in Motif requires setting the resource XmNdialogStyl to XmDIALOG_APPLICATION_MODAL for the BulletinBoard child of the DialogShell. This works perfectly under mwm but not at all together with twm Why is this so? I can think of two reasons: - Motif is designed to always require mwm. And mwm does more than what is required by the ICCCM standard. This seems to be in direct contradiction with the whole purpose of X Windows and specificly the ICCCM. - R4 twm is not compliant with ICCCM. I prefer not to belive in this one. Is there anyone who can give me some hints in this area. Thanks, Arne Lundberg European Space Technology Centre, Noordwijk, the Netherlands arne@yc.estec.nl or ALUNDBER@ESTEC.BITNET Phone: +31 1719 84865, Fax: +31 1719 12142, Telex: 39098
toml@ninja.Solbourne.COM (Tom LaStrange) (02/15/90)
> 1) The manual specifies that Dialogs should always be iconified > together with the toplevel window for the application. This does > not work when using R4 twm but (of course) when I use the Motif > windowmanager mwm. > > > Why is this so? I can think of two reasons: > > - Motif is designed to always require mwm. And mwm does more than what > is required by the ICCCM standard. There is nothing in the ICCCM (at least that I could find) that says that a transient should be removed from the display when the transient_for window is iconified. Motif and mwm decided that this was reasonable behavior, and I tend to agree with them even though it is not spelled out in the ICCCM. And it's not just transient stuff either, both Motif and Open Look specify a private protocol that their clients and their window managers understand. Are the two private protocols compatible? HAHAHAHAHAHAHAHAHAHAHAHA I guess what you really need is a window manager that deals gracefully with both Motif and Open Look clients and their private protocolisms. Hmmmmm, don't I have one of those laying around someplace ... Good Luck, Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (02/16/90)
/ hpcvlx:comp.windows.x / toml@ninja.Solbourne.COM (Tom LaStrange) / 3:27 pm Feb 14, 1990 / > 1) The manual specifies that Dialogs should always be iconified > together with the toplevel window for the application. This does > not work when using R4 twm but (of course) when I use the Motif > windowmanager mwm. > > > Why is this so? I can think of two reasons: > > - Motif is designed to always require mwm. And mwm does more than what > is required by the ICCCM standard. There is nothing in the ICCCM (at least that I could find) that says that a transient should be removed from the display when the transient_for window is iconified. Motif and mwm decided that this was reasonable behavior, and I tend to agree with them even though it is not spelled out in the ICCCM. And it's not just transient stuff either, both Motif and Open Look specify a private protocol that their clients and their window managers understand. There doesn't seem to be anything about window_group being the basis for iconification either. At least not explicitly. In R3 Xt the window_group resource (if shell) was used to set both the window_group field in WM_HINTS and the transient_for (if the window was a transient). As I said in response to the original posting (that this seems to be rehashing), I think the problem here is the ordering of creation/realization of the dialogs versus the toplevel. If that is the case then the fault is neither on twm, mwm, or the motif toolkit but rather the logic in the shell widget which is part of the intrinsics. This logic does a one shot setting of the window_group and transient_for values (which are both window ids) without waiting for the associated window to be realized. Motif 1.0 worked around this for the transient_for setting (since this is the one we use) and did not provide corrolary logic for the window_group. This can be construed as being non-ICCCM compliant, but the intent is to be ICCCM compliant and gracefully degrade in functionality when Mwm isn't present. When I brought this problem of realization ordering up during the R4 Xt design, it was not considered that this was a design flaw. The 1.1 motif toolkit will work around this for both window_group and transient_for. The reason we have a private protocol for input mode is both historical (mwm was already doing it), and human factors. Since Xt doesn't use the X focus to implement modality, you need a way to inform the window manager of what hierarchies in the application are actually in the modal set so that it can provide visual feedback on the frames. We went too far in 1.0 by placing all of the burden of modality management on Mwm, since it needed to know about it anyway. In addition, we only supported PM modal settings rather than also providing the Xt settings. We will be providing more toolkit modality support in 1.1 in order to both fix bugs with latency of Mwm setting the X focus to the new window and in order to provide full motif functionality (if not visual feedback) when running with other window managers. Gabe Beged-Dov
janssen@parc.xerox.COM (02/23/90)
In article <100920168@hpcvlx.cv.hp.com> you write: >There doesn't seem to be anything [in the ICCCM] about window_group >being the basis for iconification either. This would have been nice if it had been defined earlier, but window_group is now being used for something else by the ICCCM. This is the window on which the WM_CLIENT_MACHINE and WM_COMMAND properties are placed if the client opens multiple top-level windows (section 5.1.1). Consider an editor, for example, which opens multiple top-level windows. All of those windows are now perforce in the same window group, but it would probably not be proper behaviour to iconify and deiconify them in a group. Too bad. Bill
dshr@SUN.COM (David Rosenthal) (02/24/90)
> This would have been nice if it had been defined earlier, but window_group > is now being used for something else by the ICCCM. This is the window > on which the WM_CLIENT_MACHINE and WM_COMMAND properties are placed if > the client opens multiple top-level windows (section 5.1.1). Consider > an editor, for example, which opens multiple top-level windows. All of > those windows are now perforce in the same window group, but it would > probably not be proper behaviour to iconify and deiconify them in a group. > Too bad. > It is necessary to be very careful when you quote the ICCCM. Here are the actual words from Section 5.1.1: The client communicates with the session manager by placing two properties (WM_COMMAND and WM_CLIENT_MACHINE) on its top-level window. If the client has a group of top-level windows, these properties should be placed on the group leader window. This does not say: This is the window on which the WM_CLIENT_MACHINE and WM_COMMAND properties are placed if the client opens multiple top-level windows But rather: This is the window on which the WM_CLIENT_MACHINE and WM_COMMAND properties are placed if the client opens a group of top-level windows There is no implication that multiple top-level windows have to be in the same group, or that a client can open only one group of top-level windows, or any implication about the semantics a particular window manager chooses to apply to window groups. David.
janssen@parc.xerox.com (Bill Janssen) (02/24/90)
In article <9002231624.AA01344@devnull.sun.com>, dshr@SUN (David Rosenthal) writes: >...It is necessary to be very careful when you quote the ICCCM. Here are >the actual words from Section 5.1.1: > > The client communicates with the session manager by placing > two properties (WM_COMMAND and WM_CLIENT_MACHINE) on its > top-level window. If the client has a group of top-level > windows, these properties should be placed on the group > leader window. > ... >There is no implication that multiple top-level windows have to be in the >same group... I feel there is a very *clear* implication that top-level windows of a single client should be in the same group, and that a client with multiple top-level windows should create a group and place its top-level windows in that group. But I agree that ICCCM does not explicitly *say* this, but rather says something less precise. What does "the client has a group of top-level windows" mean? Perhaps it means that the client has created a window-group leader. But suppose the client has created more than one window-group leader. Should it place its WM_COMMAND and WM_CLIENT_MACHINE properties on each? Why? With that strategy, why not place them on every top-level window it creates? I'll argue that the only sensible interpretation of that sentence from the ICCCM is "If the client has created more than one top-level window, it should use one top-level window as a window-group leader, place its other top-level windows in that group, and place the WM_COMMAND and WM_CLIENT_MACHINE properties on that window-group leader window, but not on any other of its top-level windows." And since I have no wish to spend my life debating the fine points of ambiguous sentences, I propose that my interpretation of the sentence replace the original sentence in the ICCCM, or that the original sentence and related sentences be deleted from the document. Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
sjs@spectral.ctt.bellcore.com (Stan Switzer) (02/28/90)
In article <221@roo.UUCP> janssen@parc.xerox.com (Bill Janssen) writes: > In article <9002231624.AA01344@devnull.sun.com>, dshr@SUN (David Rosenthal) writes: > >...It is necessary to be very careful when you quote the ICCCM. Here are > >the actual words from Section 5.1.1: > > > > The client communicates with the session manager by placing > > two properties (WM_COMMAND and WM_CLIENT_MACHINE) on its > > top-level window. If the client has a group of top-level > > windows, these properties should be placed on the group > > leader window. > > ... > >There is no implication that multiple top-level windows have to be in the > >same group... > > I feel there is a very *clear* implication that top-level > windows of a single client should be in the same group, and that a > client with multiple top-level windows should create a group and place > its top-level windows in that group. But I agree that ICCCM does not > explicitly *say* this, but rather says something less precise. The ICCCM says exactly the right thing. For instance, suppose that I want to run something like WINTERP as a server into which I down load the UI part of my application. This interpreter/server might be simultaneously running several distinct application's IU drivers, but it would be, from the point of view of the server, just one client. Or consider a "deskset" suite of applications. These might all be driven all from one client but would conceptually be different applications (or not). Or consider a hypothetical extremely huge all-singing all-dancing editor. [I won't name names, but its initials are GNU :-).] You might have one of these things per client machine acting as an editing server and have an editor-client command which really just asks the editor server to pop up a new window for you. But why do *you* care how it works? There is no reason why anything in the ICCCM should preclude this architecture or any other in which a single client implements distinct "applications" (which would probably want their windows in separate groups). Stan Switzer sjs@bellcore.com