slc1290@hare.udev.cdc.com (steve chesney x4662) (05/02/91)
Our application is written with Motif 1.1 and makes heavy use of Dialog Boxes (in Dialog Shells); each of these has a title (set by the XmNtitle resource on the Dialog Shell). When we run under the Open Look Window Manager (on a Sun 4 with Open Windows 2) these dialog boxes appear with no window decoration. This means the title is not shown along with no resize handles, etc. Under mwm and twm, the window decorations, including title, do appear. What can I do so that they will also show under olwm? -- Steve Chesney Control Data Corporation slc1290@hare.udev.cdc.com
Stuart.Marks@eng.sun.COM (Stuart Marks) (05/04/91)
Our application is written with Motif 1.1 and makes heavy use of Dialog
Boxes (in Dialog Shells); each of these has a title (set by the
XmNtitle resource on the Dialog Shell). When we run under the Open
Look Window Manager (on a Sun 4 with Open Windows 2) these dialog boxes
appear with no window decoration. This means the title is not shown
along with no resize handles, etc.
I believe this occurs because Motif dialog boxes set the WM_TRANSIENT_FOR
hint. Olwm (from OpenWindows 2.0) gives transient windows very little
decoration. There's no way to change this in that version of olwm.
There may be a resource you can set to tell Motif not to set the
WM_TRANSIENT_FOR hint. I know Frame has such a resource, but I don't know
about Motif in general. Perhaps a Motif expert can respond.
s'marks
Stuart W. Marks ARPA: smarks@eng.sun.com
Windows & Graphics Software UUCP: sun!smarks
Sun Microsystems, Inc.pjb@frame.com (Paul J. Bailey) (05/06/91)
In article <32734@shamash.cdc.com>, slc1290@hare.udev.cdc.com (steve chesney x4662) writes: |> Our application is written with Motif 1.1 and makes heavy use of Dialog Boxes |> (in Dialog Shells); each of these has a title (set by the XmNtitle resource |> on the Dialog Shell). When we run under the Open Look Window Manager (on a |> Sun 4 with Open Windows 2) these dialog boxes appear with no window decoration. |> This means the title is not shown along with no resize handles, etc. olwm 2.0 doesn't decorate transient windows. This worked for us, so depending on what's hared-coded and what you can override with x resources you may have an easy or hard time of it. Maker*Transient: False If you don't care about the title, but do want resize handles, you can set this resource on your server: OpenWindows.minimalDecor: name_of_window1 name_of_window2 etc. -- Paul J. Bailey Manager, X Projects Frame Technology Corp. 1010 Rincon Circle, San Jose, Ca. 95131 Domain: pjb@frame.com Direct: (408) 922-2778 UUCP: {ames,adobe,hplabs,riacs,sun,vsi1}!frame!pjb FAX: (408) 433-1928 Frame Operator: (408) 433-3311 Please address Frame questions to: comments@frame.com
nazgul@alphalpha.com (Kee Hinckley) (05/06/91)
In article <9105031949.AA12967@trantor.Eng.Sun.COM> Stuart.Marks@eng.sun.COM (Stuart Marks) writes: >I believe this occurs because Motif dialog boxes set the WM_TRANSIENT_FOR >hint. Olwm (from OpenWindows 2.0) gives transient windows very little >decoration. There's no way to change this in that version of olwm. Well that's novel. Are there any plans to handle mapping/unmapping and iconization using that resource too? >There may be a resource you can set to tell Motif not to set the >WM_TRANSIENT_FOR hint. I know Frame has such a resource, but I don't know >about Motif in general. Perhaps a Motif expert can respond. You can of course use the standard X mechanisms to take it off, although you'd have to do it after the dialog was created - I don't know if that would matter to olwm. Of course then you have the problem that with other window managers WM_TRANSIENT_FOR does some useful things (like unmapping the dialog when you iconize the window it's transient for, or making sure it's not obscured) - so you probably don't want to turn it off all the time. I assume that's why Frame was forced to make it a user-definable resource. While we're finding out interesting things about owlm, can anyone tell me why this code results in a icon with no iconname? hints = XGetWMHints(XtDisplay(shell), XtWindow(shell)); if (!hints) { hints = (XWMHints *) XtMalloc(sizeof(XWMHints)); bzero(hints, sizeof(XWMHints)); } hints->flags = IconWindowHint; hints->icon_window = iconWindow; XSetWMHints(dpy, XtWindow(shell), hints); XtFree(hints); and later ctext = XmInternAtom(XtDisplay(widget), "STRING", False); iname = XmInternAtom(XtDisplay(widget), "WM_ICON_NAME", False); XChangeProperty(XtDisplay(widget), XtWindow(widget), iname, ctext, 8, PropModeReplace, (byte *) cptr, strlen(cptr)); -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
jody@shell.COM (Jody Winston) (05/07/91)
From greiner@shell.com: > Our application is written with Motif 1.1 and makes heavy use of Dialog > Boxes (in Dialog Shells); each of these has a title (set by the > XmNtitle resource on the Dialog Shell). When we run under the Open > Look Window Manager (on a Sun 4 with Open Windows 2) these dialog boxes > appear with no window decoration. This means the title is not shown > along with no resize handles, etc. > > I believe this occurs because Motif dialog boxes set the WM_TRANSIENT_FOR > hint. Olwm (from OpenWindows 2.0) gives transient windows very little > decoration. There's no way to change this in that version of olwm. > > There may be a resource you can set to tell Motif not to set the > WM_TRANSIENT_FOR hint. I know Frame has such a resource, but I don't know > about Motif in general. Perhaps a Motif expert can respond. > Several solutions are available: 1) The Motif shell widgets ASSUME that mwm is being used. Using another window manager, while permissible, results in depreciated functionality. For example, picture how things would look if uwm were used. Therefore, the simpliest solution is to use mwm. 2) Set the dialog shell's XmNtransient resource to FALSE. This will break the iconification code (i.e. a single icon for multiple windows) but should fix your title problem. 3) Use XtCreatePopupShell to create instances of topLevelShellWidgetClass rather than using Motif's convenience functions. This is a better way to implement option (2). It has also been tested so it's known to work.
dvb@emisle.uucp (David Van Beveren) (05/08/91)
In article <1991May6.145603.19225@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >In article <9105031949.AA12967@trantor.Eng.Sun.COM> Stuart.Marks@eng.sun.COM (Stuart Marks) writes: >>I believe this occurs because Motif dialog boxes set the WM_TRANSIENT_FOR >>hint. Olwm (from OpenWindows 2.0) gives transient windows very little >>decoration. There's no way to change this in that version of olwm. >Well that's novel. Are there any plans to handle mapping/unmapping >and iconization using that resource too? > Actually, you can modify decorations a little: (Look in the OLIT programmers guide around page 70) OLIT supports two properties, one called _OL_DECOR_ADD and the other _OL_DECOR_DEL. The properties are lists of atoms wioth names like _OL_RESIZEH _OL_TITLE, etc (I don't have the manual here). In any case, the properties listed are added or deleted from the decorations. I could add a title and resize corners to a dialog window this way. However, the title is not centered in the screen, it is way off to the right, in fact, you do not even see it unless you enlarge the window. Sun acknowledges this and gives no date for fixing it. Also, if you look in one of the OLIT include files (OlDecor.h ???) there are headers for functions that look like they might be used to modify decorations on windows, but they are not documented and I could get no help from Sun on this one. BTW: the decorations worked fine in the Beta2.0, just like they "should", with a title, resize corners and no menu. This functionality broke with the release of 2.0. The documentation I mentioned above (OLIT Programmers Guide, ~page 70) is wrong. COntact sun and they will tell you how it should be corrected. It still doesn't work quite the way they say it should, though. -- David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247
Stuart.Marks@eng.sun.COM (Stuart Marks) (05/09/91)
Are there any plans to handle mapping/unmapping and iconization using
[WM_TRANSIENT_FOR] too?
Yes. In olwm 2.0, transient windows had no title bar and no resize
corners, but they did have their own icon. In a future release of olwm,
transient windows:
- will have a title bar and resize corners, but no close button or pin
- will not have their own icon, but will iconify with their owner
- will optionally be kept stacked above their owner window, controllable
via a resource
Do y'all think this is an improvement?
If a program wants a window to be not resizable, it should set the minimum
and maximum sizes in WM_NORMAL_HINTS to be the same as the current window
size.
While we're finding out interesting things about olwm, can anyone
tell me why this code results in a icon with no iconname?
[... code to set an icon window and an icon name...]
Olwm ignores the WM_ICON_NAME property if the program has provided an icon
window. This is a bug.
s'marks
Stuart W. Marks ARPA: smarks@eng.sun.com
Windows & Graphics Software UUCP: sun!smarks
Sun Microsystems, Inc.dfc@inference.COM (Deborah Catalano) (05/10/91)
Yes. In olwm 2.0, transient windows had no title bar and no resize
corners, but they did have their own icon. In a future release of olwm,
transient windows: ^^^^^^^^^^^^^^^^
- will have a title bar and resize corners, but no close button or pin
- will not have their own icon, but will iconify with their owner
- will optionally be kept stacked above their owner window, controllable
via a resource
Do y'all think this is an improvement?
YES!! This is good news! But what do you mean by "a future release of
olwm"? Does that mean the next release?
-----------------------------------------------------------------------------
Debbie Catalano catalano@inference.com
Inference Corporation 213-322-5004 x194
"I'm a member of the LA X User's Group, not the LAX User's Group!"
-----------------------------------------------------------------------------kk@shasta.tivoli.COM (Kerry Kimbrough) (05/10/91)
> In a future release of olwm, > transient windows: > > - will have a title bar and resize corners, but no close button or pin I find this very unsatisfactory. I want a transient window to be a standard OPEN LOOK window --- base window or pop-up window. According to the above, it would be neither. Seems to me the natural form of a transient window in OPEN LOOK is a standard default command window --- pin (initially unpinned), title, no resize controls. > - will not have their own icon, but will iconify with their owner OK as a default, but why can't this be controlled by the application using the window group hint? > - will optionally be kept stacked above their owner window, controllable > via a resource Good idea.
Stuart.Marks@eng.sun.COM (Stuart Marks) (05/10/91)
But what do you mean by "a future release of olwm"?
Does that mean the next release?
Oh, I guess it means "next releaseish". :-)
s'marks
Stuart W. Marks ARPA: smarks@eng.sun.com
Windows & Graphics Software UUCP: sun!smarks
Sun Microsystems, Inc.