On Fri, Sep 02, 2011 at 10:41:33PM +0200, Pierre Frenkiel wrote:
> The base of pedagogy being repetition, I'll repeat (or summarize)
Right -- it's this sort of information you didn't supply beforehand. Now I
can explain to you why what you're seeing is not a bug.
> current setting:
> Style "xclock" NoTitle, NoHandles, Sticky, WindowListSkip, StaysOnTOP
> i.e. xclock is sticky and staysontop
> 1/ I replace by
> Style "xclock" Title
I'll simplify this a little. Let's say you did this:
Style xclock !A, B
Options "A" and "B" would apply to xclock. They're logically ORed together.
Such that when you do this:
Style xclock A
Going from ¬A to A results in this:
Style xclock A, B
Because the flag for "B" on xclock had already been set. You were just
flipping the bit for the state of "A" which had already been applied.
> Then: restart in fvwm. Result:
> The title appears immediatly on my xclock window, but
> it still is sticky and still staysontop
And this is what happens across a restart: windows are recaptured, so their
state is maintained, and applied to the same window. This is not the same
were you to have used "WindowStyle" for example, because the window ID of
xclock would have likely changed when the window was reparented to its
FW_W_FRAME.
> 2/ I close xclock, and restart it:
> it is no more sticky and doesn't staysontop
Which forces a new instance of xclock to be looked up by the style matching
code, and hence applied.
> I can't say I have found a bug, as you swear it works for you, but I would
> like
> to know what happens for other people. May be we could then find what
> explains
> the difference of behaviours.
HTH,
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
