Chris's Wiki :: blog/unix/FvwmKeyboardWindows Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/FvwmKeyboardWindows?atomcommentsDWiki2012-02-12T00:34:16ZRecent comments in Chris's Wiki :: blog/unix/FvwmKeyboardWindows.By Chris Siebenmann on /blog/unix/FvwmKeyboardWindowstag:CSpace:blog/unix/FvwmKeyboardWindows:4ca1b38fc4851b0b2d775cad0cc31df72d884d35Chris Siebenmann<div class="wikitext"><p>Oh! I suddenly see my misunderstanding; I did not realize that windows
could be in several states at once. I thought it was exclusive, so that
a window in State 1 could not also be in State 2. Non-exclusive States
answer my concerns completely and make States the right answer for what
I'm doing here.</p>
<p>This is an especially stupid misunderstanding on my part because the
documentation more or less explicitly describes them as separate (in
the description of <code>State</code> in the FVWM manpage). I just never read the
documentation carefully enough. So this one is my fault.</p>
</div>2012-02-12T00:34:16ZFrom 188.222.193.222 on /blog/unix/FvwmKeyboardWindowstag:CSpace:blog/unix/FvwmKeyboardWindows:3328d4db34b7f6c5e1031710e51d069f2f9dc7f5From 188.222.193.222<div class="wikitext"><blockquote><p>Suppose that I want to use a State to mark things as browser windows (as I'm doing here with terminal windows); I assign such windows State 1 as part of applying my general 'browser' style to them. I also want to use a State to mark things that have not had been iconified and had their icon placed yet; I assign such windows State 2. So what is the State of a browser window that has not yet had its icon placed, and how do I match and manipulate this state?</p>
</blockquote>
<p>In much the same way you would in your first example, but with a means of tracking iconified state of windows, which is what FvwmEvent is for. But note that you're committing the naughtiest of sins here and deciding your situation in the specific case rules out <em>any</em> use of the general case. Here:</p>
<p>DestroyModuleConfig FE:*
*FE: iconify "WindowStyle (!State 2) State 2"
*FE: deiconify "ThisWindow (State 2) !State 2"</p>
<p>For anything more specific, such as applying this state only when you've manually placed icons somewhere, you'd need to bind a function to a +M operation which did the above afterwards. Either way, I don't mind. Whether you need to clear out State 2 at all is up to you -- the point is, it's an example to allow you to do whatever you need.</p>
<p>But the state of a browser window which has not had its icon placed yet, is always one which does not have State 2 defined, but can have any other states attached to it, depending on the condition(s) you want to perform on the windows.</p>
<ol><li>Match a window with both States 11 and 12 on it:</li>
</ol>
<p>Next (State 11, State 12) Focus</p>
<ol><li>Match one specific window:</li>
</ol>
<p>Next (State 12) Focus</p>
<blockquote><p>(I think that you can sort of do this in FVWM today but it's awkward, because you are basically writing out all of the cases for an emulation of bitfields. You'd have to match both State 2 and State 3, and then if you label some other sort of windows with their own state you expand the matching and so on.)</p>
</blockquote>
<p>Not really.</p>
<blockquote><p>Thinking about this led me to the conclusion that I should probably save States for things that really can't be handled any other way, things where I need to mark essentially arbitrary state transformations that can't be matched in other ways. Using States simply as shorthand markers may be slightly more convenient in the short term but runs into long-term problems if you later need States for, well, state markers.</p>
</blockquote>
<p>In which case you're mis-thinking the whole point of what a "state marker" is, and just because internally FVWM uses a bit-field to mark these windows, does not mean you, as a user, have to use them in that way. </p>
<p>-- Thomas Adam</p>
</div>2012-02-12T00:21:32ZBy Chris Siebenmann on /blog/unix/FvwmKeyboardWindowstag:CSpace:blog/unix/FvwmKeyboardWindows:681b5a0fa08e3c6066136b56e3a265fc8d7089baChris Siebenmann<div class="wikitext"><p>Let me try to show what I meant with a real(ish) example.</p>
<p>Suppose that I want to use a State to mark things as browser windows (as
I'm doing here with terminal windows); I assign such windows State 1 as
part of applying my general 'browser' style to them. I also want to use
a State to mark things that have not had been iconified and had their
icon placed yet; I assign such windows State 2. So what is the State
of a browser window that has not yet had its icon placed, and how do I
match and manipulate this state?</p>
<p>(I think that you can sort of do this in FVWM today but it's awkward,
because you are basically writing out all of the cases for an emulation
of bitfields. You'd have to match both State 2 and State 3, and then if
you label some other sort of windows with their own state you expand the
matching and so on.)</p>
<p>Thinking about this led me to the conclusion that I should probably
save States for things that really can't be handled any other way,
things where I need to mark essentially arbitrary state transformations
that can't be matched in other ways. Using States simply as shorthand
markers may be slightly more convenient in the short term but runs into
long-term problems if you later need States for, well, state markers.</p>
<p>Even if I was successfully using States for 'has not been iconified and
had its icon placed yet' in my FVWM configuration, I could get away with
it today because terminal windows are never iconified to icons. But I
can't use the same approach for other 'tag a class of windows' uses,
and I could face problems in the future if I want to use States for
something that terminal windows overlap with.</p>
</div>2012-02-12T00:05:35ZFrom 188.222.193.222 on /blog/unix/FvwmKeyboardWindowstag:CSpace:blog/unix/FvwmKeyboardWindows:64e99d4d8a2820ff8fa92da3adf97ba1df711842From 188.222.193.222<div class="wikitext"><p>Well, I think you're misunderstanding a lot of things here -- you can have up to 32 states for anything you deem appropriate, and in your case you can have one for your terminal windows and others for icon positioning and <em>still</em> test for one or the other or both in conditional commands, depending on your needs.</p>
<p>Certainly, my original outline to your for the use-case you specified will work, but it seems to me as though there's a lot more detail you failed to mention, and it's slightly detrimental to your recommendations in your post, because my general hints to you to use State were correct; and to not mention them in your post just leads to a load of unnecessary complexity. Which, when you're trying to lend advise on things you've discovered to other people, should be correct as much as possible. As it reads now though, it's almost there, but not quite. And if I've learnt anything from all the years of support for different software, it's that there's nothing worse than correcting posts of well-intended enthusiasts. ;P</p>
<p>-- Thomas Adam</p>
</div>2012-02-11T21:54:53ZBy Chris Siebenmann on /blog/unix/FvwmKeyboardWindowstag:CSpace:blog/unix/FvwmKeyboardWindows:8c9a3e3299b920ddc608407b4abb88f42c08b916Chris Siebenmann<div class="wikitext"><p>I started to do a version with State and then thought that using State
for this would immediately clash with using State for icon placement
if I got that working in a future version of FVWM. Writing this now
I've just realized that that isn't the case because I iconify terminal
windows to FvwmIconMan so that them not being handled properly for a
State-based icon placement doesn't matter; they never have desktop icons
to be placed.</p>
<p>The real problem with State as I was about to use it is that what I want
is effectively a bitmap of options, not a single label for windows. The
'is or is not a terminal window' option is not related to the 'has had
its icon placed' option (or any future option I want), but I have to
somehow fold them both into a single label with State. Even now I'm not
sure I want to lock myself into a single use for states for terminal
windows when I don't have to.</p>
<p>Possibly I'm missing something about how to use States cleverly to get
overlapping options.</p>
</div>2012-02-11T21:10:45ZFrom 188.222.193.222 on /blog/unix/FvwmKeyboardWindowstag:CSpace:blog/unix/FvwmKeyboardWindows:739a2c6e2f608d20d4ce2976ec59eccdfe24ccbfFrom 188.222.193.222<div class="wikitext"><p>Disappointing not to see you use State here, as we discussed previously.</p>
<p>-- Thomas Adam</p>
</div>2012-02-11T10:45:11Z