Submitted by Anonymous on Fri, 05/04/2001 - 16:35. Developers
How can I find out, if a window of a application is iconified or not?
(like if a special window is iconified, than put another window in the left corner, if not, than put it to the right...)
Mon, 07/02/2012 - 14:29
#1
Iconified window
This is how I am doing it for several years now. The code is so old, that I can no longer remember if I wrote it based on some tip in a FAQ somewhare or was it my idea...
static void stateWatcher(Widget w, XtPointer
clientData, XEvent *event)
{
if (event->type == UnmapNotify)
{ /* do whatever is necessary */ }
}
int main(...)
{
...
XtRealizeWidget(appShell);
XtAddEventHandler(appShell, StructureNotifyMask,
False, (XtEventHandler) stateWatcher, NULL);
...
}
While on topic of iconizaiton - I have a question,
too. When I run my Motif app on KDE, with working
dialog (like print progress), and I iconize the program, something strange happens. When program unmaps the working dialog (since printing is finished), the dialog suddenly pops up and stays there and refuses to be killed. Something like "zombie" window. Same thing happens if I use several workspaces.
Apparently KDE window manager handles WM hints in a different (I do not dar to say nonstandard) manner. I do now want to introduce special code to handle different window managers. Should we lobby the KDE developers to fix this?
Or is Motif too old and does not cover advanced situations like multiple workspaces. In that case, Motif should be fixed.
What do you folks think of this problem?
Dusan
Thx for the code... I found something like that in a FAQ (search by google Motif FAQ)
I`m interested in motif only for a few days, so I can`t say anything of the KDE-Problem (Couldn`t it help, if you restore the window before unmapping it? It sounds like a list-handle-failure of the shown and the iconified windows... can you specify this by your program on unmapping?)
The ghost dialog is not a KDE or Motif problem. The reason for this is with X, or maybe Xt. If you XtManage a dialog, then very quickly XtUnmanage the dialog, you will sometimes be left with the ghost. The problem is because of the async nature of X. When the dialog is managed the process of showing the window is started. Before this process is finished, you unmanage the dialog, the process gets stopped, but it seems that a few commands have still leaked out, and you end up with a window on the screen that doesn`t really exist. If you have a dialog that may be managed, then unmanaged very quickly you have to wait till the dialog has been mapped before you unmanage it.
The XltWorking dialog handles this situation. Checkout Xlt at www.lesstif.org.
Thank you for your ideas, rwscott.
Unfortunately, my dialog is mapped before I unmanage it. My program is smart enough not to pop-up working dialogs on small jobs ;-)
The situation happens on big print jobs, when it takes like 30 seconds, so you iconize the window to work on something else in the mean time. Besides, it works nicely on "mwm", this problem happens only on KDE.
Dusan