lindholm@greve.ucs.ubc.ca (George Lindholm) (03/15/91)
What do I have to do so that my program can run while iconized? -- George Lindholm phone: (604) 822-4375 University Computing Services internet: lindholm@ucs.ubc.ca University of British Columbia bitnet: USERGNL@UBCMTSG 6356 Agricultural Road, Vancouver, B.C., Canada, V6T 1T7
rthomson@mesa.dsd.es.com (Rich Thomson) (03/15/91)
In article <1991Mar14.232039.1950@unixg.ubc.ca> lindholm@greve.ucs.ubc.ca (George Lindholm) writes: >What do I have to do so that my program can run while iconized? I've usually seen the state referred to as "iconified", or "iconic state". Anyway, you're program continues to run as usual when you're application has been iconified by the window manager. You will get an unmap event and a property notify event (if you're window manager is ICCCM compliant you'll get an event notifying you that your WM_STATE property has changed). What the window manager does is to unmap the application window and map (or create and map) the icon window. Since your application's window is unmapped, all output to the window will not appear on the screen. Your application will continue to run however; the window manager doesn't do anything to the process that created the window (and quite possibly couldn't even if it wanted to -- the process could be running quite literally on another continent). Now, if you're asking how to get button events, key presses, etc. when you're application is iconified, you can get the window ID of the icon window and select for input on that window like any other window. Whether or not this is a good idea remains an open question. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
dshr@eng.sun.COM (David Rosenthal) (03/17/91)
> Now, if you're asking how to get button events, key presses, etc. when > you're application is iconified, you can get the window ID of the icon > window and select for input on that window like any other window. > > Whether or not this is a good idea remains an open question. > The ICCCM Section 4.1.9 (page 530 of the Digital Press 2nd Edition) says: 8. Clients must not depend on being able to receive input events by means of their icon windows. ..... Window managers will differ as to whether they support input events to client's icon windows; most will allow the client to receive some subset of the keys and buttons. What this means is that it is OK to have your client do the appropriate this *if* it receives a keystoke or button press via its icon window, and thus that it is perfectly OK to select for these events on the icon window, but it must not be essential to the operation of the client that it receive such an event. Note that events may arrive via the icon window at any time. It is not a good assumption that the icon window is unmapped when the top-level window is mapped. For eample, some window management styles have an icon permanently visible irrespective of whether the main window is visible or not. Other styles will never make the icon window visible. So defensive programming is in order - do not *depend* on the icon doing anything at all, but do make it do the right thing if it is visible, and if it gets events, and so on. David.
meo@Dixie.Com (Miles ONeal) (03/18/91)
David Rosenthal writes (and we all litsen 8^): (quoting the IC3M) | Window managers will differ as to whether they support input events | to client's icon windows; most will allow the client to receive some | subset of the keys and buttons. |What this means is that it is OK to have your client do the appropriate |this *if* it receives a keystoke or button press via its icon window, |and thus that it is perfectly OK to select for these events on the icon |window, but it must not be essential to the operation of the client that |it receive such an event. Of course, there is the additional problem of conflict between menu manager mapping vs client mapping. You want to make the client useful without aggravating the user. It is therefore not a good idea to have anything important expect a button1 event on an icon, for instance, or even a button2 or button3 event, as these, in various guises, are all used by various window managers for opening, moving, etc. Of course, the user can remap the icon events (you DID use the TM, eh?). BUT, if the normal, desired behavior in the uniconified client involves these buttons, the user will expect do the same thing in the same way in the iconified client. So you should have not only an excellent reason to do this, but you have to convey to the user why this is worth their while in extra setup time, retraining, or whatever. -Miles meo@dixie.com