twl@cadreri.UUCP (Todd W. Lainhart) (03/14/91)
Hello xperts -
I have some questions regarding window manager hints in general. It's my hope that
I can clear up a bug in my application.
Here's the problem: I have an application running under OpenWindows 2.0. From
time to time (and I don't know how to duplicate this condition) my application
"loses" its icon pixmap, and no longer appears to be receiving keypress events.
Of course, this stuff is setup in a window hints data structure similar to the
following:
wmhints.flags = InputHint;
wmhints.input = True;
wmhints.icon_pixmap = XCreatePixmapFromBitmapData(...);
wmhints.flags |= IconPixmapHint;
Now, Chapter 10 of O'Reilly Vol 1, on page 303 states the following:
"The window manager is encouraged to honor as many of the hints as possible,
but it is not required to honor any of them. Therefore, the application must
not depend on its hints being honored; it must be capable of operating when
any of its hints are ignored or denied."
It looks like my hints are being ignored for mysterious reasons. So if that's the
case, how do I best handle setting the input focus? It seems somewhat kludgy to
set the input focus when my X window (I have only one) gets an EnterNotify event,
and then to release the input focus to the root window when I get a LeaveNotify,
but that's just what the code I'm looking at now does - I think a more elegant
solution is required. BTW, I did notice a potential bug in my application -
it appears that these properties are being set *after* the window has been mapped.
O'Reilly, and other code that I've seen, set the properties *before* the window
has been mapped. This could be a problem...
I guess I could generalize the question and ask, "If there's no window manager,
how does one best set/relieve input focus for applications". Also, I'm assuming
that the input model for an application that consists of a single X window (but
has its own model within the window of graphic object selection and navigation)
would be one of "Passive Input" - in other words, the application has the input
focus when the window manager tells it to. It appears that if I use the
Passive Input model, I don't need to be concerned with WM_TAKE_FOCUS messages from
the window manager.
Also, another question: I notice that O'Reilly also suggests using XSetWMProperties(...)
over XSetWMHints(...) (although I can find no man pages on the former call). Is
the distinction important, or are the calls just wrappers over more primitive calls?
I've looked through my copy of FAQ (I don't know how old it is...), and I don't see
anything related to this.
Thanks for your consideration.
-- Toddsmarks@eng.sun.COM (Stuart Marks) (03/16/91)
Here's the problem: I have an application running under OpenWindows
2.0. From time to time (and I don't know how to duplicate this
condition) my application "loses" its icon pixmap, and no longer
appears to be receiving keypress events.
Does a running application lose the ability to accept keystrokes, and does
it lose its icon, or does the behavior differ from one run of the
application to the next?
It looks like my hints are being ignored for mysterious reasons. So if
that's the case, how do I best handle setting the input focus? It
seems somewhat kludgy to set the input focus when my X window (I have
only one) gets an EnterNotify event, and then to release the input
focus to the root window when I get a LeaveNotify, but that's just what
the code I'm looking at now does - I think a more elegant solution is
required.
Not only is it kludgy, it's wrong! You're right in thinking that a
different solution is required.
BTW, I did notice a potential bug in my application - it appears that
these properties are being set *after* the window has been mapped.
O'Reilly, and other code that I've seen, set the properties *before*
the window has been mapped. This could be a problem...
Yes, this is probably it. If the behavior differs from one invocation of
the application to the next, then this is most likely what is causing the
problem. olwm (the window manager in OpenWindows) reads hints when the
program maps the window. If the program is writing those hints after it
maps the window, there's a race condition between the program writing the
hints and olwm reading them. It is best to always set the properties
before mapping the window. This will ensure that they are always
available when the window manager needs to read them.
[A possible approach to solving this problem is to have the window manager
re-read hints whenever they change. This is good for supporting truly
dynamic behavior, but it's bad because it covers up sloppy programming.]
I guess I could generalize the question and ask, "If there's no window
manager, how does one best set/relieve input focus for applications".
Your program should rely on having a window manager around to manage the
focus. If there is no window manager, the user is pretty hosed already,
because he won't be able to move, resize, open, close, etc. the windows in
the first place.
Also, I'm assuming that the input model for an application that
consists of a single X window (but has its own model within the window
of graphic object selection and navigation) would be one of "Passive
Input" - in other words, the application has the input focus when the
window manager tells it to. It appears that if I use the Passive Input
model, I don't need to be concerned with WM_TAKE_FOCUS messages from
the window manager.
Correct.
Also, another question: I notice that O'Reilly also suggests using
XSetWMProperties(...) over XSetWMHints(...) (although I can find no
man pages on the former call). Is the distinction important, or are
the calls just wrappers over more primitive calls?
These calls are all wrappers around the XChangeProperty() call, but that
call is complex enough that I'd recommend using these "convenience"
functions wherever possible. It will make your code simpler and less
error-prone. XSetWMProperties() was added in X11R4, so some older
documentation may not have it. It's basically a superset of XSetWMHints().
s'marks
Stuart W. Marks ARPA: smarks@eng.sun.com
Windows & Graphics Software UUCP: sun!smarks
Sun Microsystems, Inc.