Q: Which are the atoms I can pass to wm protocol ?
Iond Research Srl
guys.
The question is the one stated in the object.
Particularly, I would like to control the minimize button, with something
like WM_ICONIFY_WINDOW or WM_MINIMIZE_WINDOW, if possible
Thanks for your time and help
Bye
Luca
Timothy Trainor
>
> Hi,
> guys.
>
> The question is the one stated in the object.
> Particularly, I would like to control the minimize button, with something
> like WM_ICONIFY_WINDOW or WM_MINIMIZE_WINDOW, if possible
One idea would be to bind a procedure to the toplevel window's <Unmap>
event.
bind . <Unmap> {puts "%W has been minimized"}
Iond Research Srl
Timothy Trainor <ttra...@berkshire.net> wrote in message
37625EC6...@berkshire.net...
Great,
I will surely use it, but the main question is still not answered
Thanks a lot
Luca
Joe English
Iond Research Srl <io...@tin.it> wrote:
>Timothy Trainor <ttra...@berkshire.net> wrote
>> Iond Research Srl wrote:
>> >
>> > The question is the one stated in the object.
>> > Particularly, I would like to control the minimize button, with
>> > something
>> > like WM_ICONIFY_WINDOW or WM_MINIMIZE_WINDOW, if possible
>>
>> One idea would be to bind a procedure to the toplevel window's <Unmap>
>> event.
>>
>> bind . <Unmap> {puts "%W has been minimized"}
>
The ICCCM version 2.0 [1] only defines three protocols;
WM_DELETE_WINDOW (the window manager "Close" function),
WM_TAKE_FOCUS (which you absolutely do not want to set
unless you know what you're doing), and WM_SAVE_YOURSELF
(which [used to be] used for for session management.)
There is no standard WM_PROTOCOL message for iconification/minimization.
If you want to detect when this happens, catching <Unmap> events is
probably the best approach, but see the ICCCM for more details.
The WM_SAVE_YOURSELF protocol is not widely used, and it's
deprecated as of X11R6 (in favor of something truly horrible,
which AFAIK nobody uses either).
If you do decide to catch WM_SAVE_YOURSELF, the handler must
respond by updating the WM_COMMAND property (you can do this
in Tk with the 'wm command' command). The handler should also
save the state of the application if that's appropriate. From
the ICCCM:
| Clients that receive WM_SAVE_YOURSELF should place them-
| selves in a state from which they can be restarted and
| should update WM_COMMAND to be a command that will restart
| them in this state. The session manager will be waiting for
| a event on WM_COMMAND as a confirmation that the client has
| saved its state. Therefore, WM_COMMAND should be updated
| (perhaps with a zero-length append) even if its contents are
| correct. No interactions with the user are permitted during
| this process.
|
| Once it has received this confirmation, the session manager
| will feel free to terminate the client if that is what the
| user asked for. Otherwise, if the user asked for the ses-
| sion to be put to sleep, the session manager will ensure
| that the client does not receive any mouse or keyboard
| events [... until the user wakes the session back up]
Note also that the WM_SAVE_YOURSELF handler should *not* exit
the application (it's a checkpoint request, not a termination
request). Some window managers send WM_SAVE_YOURSELF on a
regular basis to checkpoint the desktop state.
Some window/session managers may define extra protocols as well.
SGI's 4DWm uses the '_WM_QUIT_APP' as an "exit program" message
(this is different from 'WM_DELETE_WINDOW' if there are multiple
top-level windows). And Motif programs apparently use a protocol
called '_MOTIF_WM_MESSAGES'; naturally this protocol is completely
undocumented.
Hope this helps,
--Joe English
[1] ICCCM: Inter-Client Communications Conventions Manual.