If value is specified, this command stores value in window 's WM_COMMAND property for use by the window manager or session manager and returns an empty string. Value must have proper list structure; the elements should contain the words of the command used to invoke the application. If value isn't specified then the command returns the last value set in a wm command command for window. If value is specified as an empty string, the command deletes the WM_COMMAND property from window.
wm is a Tk command. It has a number of subcommands (sometimes referred to as minor commands). wm command is one of these minor commands.
I presume someone is contemplating creating a page to talk about how one uses the wm command subcommand effectively.
The wm command command is used to provide some level of compliance with the ICCCM. In order for the session manager to be able to restore an application, it must know how to start that application. The most basic way to do this is:
wm command . [linsert $argv 0 $argv0]
You should also use the wm client command to set the application client, thus:
wm client . [info hostname]
MGS [2003/09/04] - Actually, things are a little more complicated than this. When Tk loads (either via invoking 'wish', or by using 'package require Tk'). it steals command-line arguments for its own use. For instance:
$ wish -name myapp -geom 200x200 -sync file1 file2 % set argv file1 file2
Tk has stolen the arguments -name myapp -geom 200x200 -sync. In order to set the wm command properly, these arguments must be retrieved, and combined with $argv to form a complete command-line.
# ======================================================================
# wm:command --
# Description
# Set wm command using all tk command-line options
# Arguments
# W : application window
proc wm:command {W} {
# ----------------------------------------------------------------------
set args [list [info nameofexecutable]]
if { !$::tcl_interactive } { lappend args $::argv0 }
# ----------------------------------------------------------------------
set colormap [::$W cget -colormap]
if { [string length $colormap] } { lappend args -colormap $colormap }
set display [::$W cget -screen]
if { [string length $display] } { lappend args -display $display }
if { [info exists ::geometry] } { lappend args -geometry $::geometry }
# TODO: allow for 'appname #1' etc
lappend args -name [tk appname]
# NOTE: can't handle -sync option
set use [::$W cget -use]
if { [string length $use] } { lappend args -use $use }
set visual [::$W cget -visual]
if { [string length $visual] } { lappend args -visual $visual }
# ----------------------------------------------------------------------
set argv [concat $args [list --] $::argv]
wm command $W $argv
# ----------------------------------------------------------------------
return
}
# ======================================================================
# example code - start with:
# wish thisfile.tcl -name myapp -geom 200x200 -sync file1 file2
wm:command .
puts "wm command . = \[[wm command .]\]"
# and don't forget
wm client . [info hostname]
# ======================================================================which should output:
wm command . = [/usr/local/bin/wish /tmp/wmcommand.tcl -geometry 200x200 -name myapp -- file1 file2]
And xlsclients -l (on Unix) should give something like:
Window 0x3e00004: Machine: host.domain.com Name: myapp Command: /usr/local/bin/wish /tmp/wmcommand.tcl -geometry 200x200 -name myapp -- file1 file2 Instance/Class: myapp/Myapp
LV Anyone know why, by default, Tk applications are not listed by xlsclients?
One thing I don't understand: if you start an app on a server but display it on a remote display, and then log out of that display, and log back in, how is that display supposed to start the app on the server? rsh?
MGS [2003/09/30] - I think it uses the rstart protocol.