On Tue, Sep 20, 2011 at 06:54:47PM -0400, Nikos Leonardos wrote:
> One way to do that would be to use the fact that the window name
> is different in each mode. It is "xboard" in mode (1) and it is
> "xboard: 69.36.243.188" in mode (2). However, this doesn't seem
> to be entirely true. I think what happens is that initially (at
> the time the style of the window is determined) the window name
> _is_ the same.
Quite possibly it is for the resource and class, yes. You cannot change the
class name of a window once it has left the Withdrawn state. The window
name is free to change, and in the case of a window title denoting the IP
address of the server the client is connecting to, it's more than likely
only setting its WM_NAME property once it has established it has a
connection to the server. You can verify this using "xprop -spy" and such
if you really wanted to, although I suspect such things are only academic
where you're concerned.
> One way around that, is to use (the obsolete command)
> RecaptureWindow after the window name has changed. I don't like
> this because of the extra keystrokes I need to do.
What makes you think you even need to use it? I would bet any money you
don't, and I would go as far as to suggest whichever solution you're using
is causing the problem with a recapture more than anything else. Even if
the title of the window did change, that won't stop you from using solutions
like this (I'm assuming the class name of this application is "XBoard", you
can use FvwmIdent/xprop/xwininfo to find out):
DestroyModuleConfig FE:*
*FE: add_window somefunction
AddToFunc StartFunction I Module FvwmEvent FE
DestroyFunc somefunction
AddToFunc somefunction
+ I All (XBoard, !State 1) Next (XBoard) WindowStyle State 1
+ I TestRc (NoMatch) ThisWindow (XBoard) dosomethingwithnewwindow
Obviously, "dosomethingwithnewwindow" is whatever you wanted to have happen
with the other window matching the XBoard class name, but which was somehow
different to the first instance of the window already matched, because we've
assigned it a window state of "1" in this case. Admittedly it's not very
scientific, so you might need to do more complex things here, but the
general ethos shown above should be enough to give you ideas.
XBoard used to be linked against Xt directly which would have made setting
the window name directly more easier via resources. But ISTR upstream are
now using GTK which sucks for Xboard IMO. Still, lobby them to add such an
option, would you? It would be a trivial addition. Relying on the window
title to change through certain options where those options might only
change the window title as a result of the current state of the program --
and where those options are not solely responsible for changing the window
title, is only going to stop working a lot sooner in the future, to be
honest.
Now, with all of the above said, this is another reason why I wrote the
{Icon,Title}Format code which is currently sat in CVS, but will form part of
the 2.6.3 release at the end of this month. With that, you'll be able to do
things like this:
Style XBoard InitialMapCommand checkwindow
DestroyFunc checkwindow
AddToFunc checkwindow
# If this is the first window...
+ I None (XBoard, ...) WindowStyle TitleFormat SomeSpecialName
+ I Next (!"SomeSpecialName") WindowStyle TitleFormat ...
Note that you can embellish this with TestRC (...) and what have you to make
it more sophisticated. The nice thing about InitialMapCommand and style
lines is they run in the named window context of the matched window, without
needing to do superfluous checks which you've already seen with my examples
above using FvwmEvent.
> I would like to do that automatically, say through an
> fvwm-function that calls xboard and also sets the appropriate
> style. I tried something like the following, but it didn't work.
>
> DestroyFunc FvwmFics
> AddToFunc FvwmFics
> + I Exec exec $[TERM] -e /usr/games/bin/xboard -ics -icshost 69.36.243.188
> + I Wait "xboard: 69.36.243.188"
> + I All ("xboard: 69.36.243.188") WindowStyle NeverFocus, Title
See above. And as I've mentioned very recently on this list, the use of
"All" here, when you mean *next*, is something to heed.
> + I UpdateStyles
Not needed anymore. Please also use 2.6.2, since the version of FVWM you
list is ancient in development terms.
-- Thomas Adam
--
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.
