Uucp@resq.fidonet.org (Uucp) (03/26/91)
From uunet!osf.org!motif-talk-request
From: uunet!neptune.fx.com!mikew
To: motif-defect@osf.org, motif-talk@osf.org
Date: Mon, 25 Mar 91 10:05:55 -0800
OSF/Motif Problem Report
=================================
Submitter Information (Include if not in News/mail headers)
---------------------
Submitter Name: Mike Wexler
Organization: FXD/Telerate, Inc.
Email Address: mikew@fx.com
Phone: 415-961-3377
OSF License Number: 168-S-90
Hardware/Software Configuration
-------------------------------
Offering and Version: Motif 1.1.1
Component (Module): doc/XmProcessTraversal.3
Client Hardware: Sun 4/60, 28 Megabytes
Client Software: Sun OS 4.1.1, X11R4
Server Hardware: SAME AS CLIENT
Server Software: Sun OS 4.1.1, OpenWindows
Compiler: cc (Sun)
Problem Description
-------------------
Severity Level:
Severe -- represents a problem which resulted in software functionality
limitation but had alternative work-around.
Date of First Occurrence:
3/1/91
One Line Description:
Doesn't state that traversal requires a mapped window.
Full Description:
The man page doesn't state the XmProcessTraversal will only allow
traversal to widgets that are currently mapped.
Repeat By:
Read the man page.
Proposed Solution:
Add text to the man page.
--
Uucp - via FidoNet node 1:269/133
UUCP: uunet!resq!UucpUucp@resq.fidonet.org (Uucp) (03/26/91)
From uunet!osf.org!motif-talk-request
From: uunet!neptune.fx.com!mikew
To: motif-defect@osf.org, motif-talk@osf.org
Date: Mon, 25 Mar 91 10:10:15 -0800
OSF/Motif Problem Report
=================================
Submitter Information (Include if not in News/mail headers)
---------------------
Submitter Name: Mike Wexler
Organization: FXD/Telerate, Inc.
Email Address: mikew@fx.com
Phone: 415-961-3377
OSF License Number: 168-S-90
Hardware/Software Configuration
-------------------------------
Offering and Version: Motif 1.1.1
Component (Module): lib/Xm/Travesal
Client Hardware: Sun 4/60, 28 Megabytes
Client Software: Sun OS 4.1.1, X11R4
Server Hardware: SAME AS CLIENT
Server Software: Sun OS 4.1.1, OpenWindows
Compiler: cc (Sun)
Problem Description
-------------------
Severity Level:
Enhancement -- represents a request for enhancement of the software.
Date of First Occurrence:
3/25/91
One Line Description:
Need an XmNinitialTraversalCallback resource in Manager widget.
Full Description:
When writing a widget that is a sub-class of Manager, it is very, very
difficult to reliably specify which widget should get the initial
focus.
Repeat By:
Write a widget that is a sub-class of the manager widget. Ask your
UI people which component should get the initial focus. Try to
implement their recommendation.
Proposed Solution:
See the one line description. BTW, I hear this is planned for 1.2.
--
Uucp - via FidoNet node 1:269/133
UUCP: uunet!resq!Uucpnazgul@alfalfa.com (Information Junkie) (04/13/91)
First a brief note. When posting bug reports could people please use the one-line description as the Subject rather than a generic title? It would make it a little easier for those of us who file them away for future reference. > When a primary window is withdrawn Mwm will withdraw any associated > secondary windows. The toolkit and application will be unaware of this ... > via a call to XtPopdown. This means that you are responsible for either > tracking map/unmap notifies and guessing whether you're withdrawn vs > iconic or always calling XtPopdown before calling XtPopup on the secondary. It should be noted that if you want this behavior (dialogs disappear when parent is iconified, come back when you deiconify) you'd better do it yourself anyway, because it's a feature of Mwm that isn't present in other window managers (like Olwm). There are two ways you could do this. One is to keep track of all of your dialogs. The other follows. (I actually have a couple questions here. In particular, what is "WithdrawnState" and when might it happen? Should I be unmanaging my dialogs there too?) I've done a quick de-C++ing of this code; my apologies if I missed anything. /* // propertyCB code concept curtesy Weidong Wang */ static void propertyCB(Widget w, XtPointer udata, XEvent *event, Boolean *) { Atom actual_type; int actual_format; unsigned long nitems, bytes_after; unsigned char *data; long *state; XPropertyEvent *pevent = (XPropertyEvent *) event; Widget dialog = (Widget) udata; if (pevent->type == PropertyNotify) { if (XGetWindowProperty(pevent->display, pevent->window, pevent->atom, 0L, 1L, False, AnyPropertyType, &actual_type, &actual_format, &nitems, &bytes_after, &data)) return; state = (long *)data; switch (*state) { case NormalState: XtManageChild(dialog); break; case IconicState: XtUnmanageChild(dialog); break; case WithdrawnState: break; default: break; } XFree((char *)data); } } void handleIconize(Widget shell, Boolean on) { Widget tshell; /* We are searching for the first *application* shell, since that's what will * get iconified. */ for (tshell = XtParent(shell); tshell && !XtIsApplicationShell(tshell); tshell = XtParent(tshell)); if (tshell) { if (on) { XtAddEventHandler(tshell, PropertyChangeMask, False, propertyCB, (XtPointer) this); } else { XtRemoveEventHandler(tshell, PropertyChangeMask, False, propertyCB, (XtPointer) this); } } } Now all you have to do is whenever you manage the dialog, call handleIconize(dialog, True). This will install an eventHandler on the applicationShell that is the parent (direct or indirect) of the dialog. You can call it multiple times safely, so you don't have to keep track of that. The most important thing to keep track of is that you *must* call handleIconize(dialog, False) before deleting the dialog! So don't let any "Cancel" callbacks automatically delete the thing or you'll be in for a big suprise the next time you iconify your window. Fortunately it's safe to call that multiple times too. One other thing. Sometimes you may cache a dialog for future use. In that case be sure to call handleIconize(dialog, False) so it doesn't uncache itself unexpectedly. An interesting side effect of this code is that it showed me that I was leaking dialogs in my application. There were a number of cases where I was unmanaging but not deleting dialogs (the joys of stateless, async applications). With this handler installed, these dialogs come back the first time you deconify the app. Enjoy. 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.