My StartsOnPage patch now looks pretty solid - I've been running
the latest version for about a week with no, er, surprises. I'd welcome
any comments from testers, both as to its stability, and more importantly,
as to how people think it *ought* to behave.
It's rather large (36K), so I'd rather not spam the mailing
lists with repeated versions. It can be fetched from
http://www.pcnet.com/~proteus/Fvwm/FvwmPatches.html
Usage:
------
1) New Style:
Style StartsOnPage d x y
where d = the target desktop, and x and y = the x and y page
numbers.
If only one arg is used, it works like StartsOnDesk.
If 2 args, they specify the page with no desk preference.
It shares the StartsOnDesk Style flag, so you don't have
to give up some other style. Existing StartsOnDesk code is
used, where possible, without functional modification: 2 small
exceptions are noted below.
2) 3 temporary GlobalOpts pairs for customizing its behavior
(defaults appear first):
CaptureHonorsStartsOnPage/CaptureIgnoresStartsOnPage
RecaptureIgnoresStartsOnPage/RecaptureHonorsStartsOnPage
StartsOnPageHonorsUSPosition/StartsOnPageModifiesUSPosition
I personally think that 2 of the 3 options are a bit of overkill,
but I put them in to allow testers (including myself) to try out
different behaviors to see what they really find useful.
How It Behaves: (rather well, actually)
---------------
1) StartsOnPage is honored for initial placement of new
windows, and for initial capture of windows existing
prior to startup.
2) By default, StartsOnPage (or StartsOnDesk) placement *is not*
honored during a Restart or Recapture, but this can be
overridden by GlobalOpts RecaptureHonorsStartsOnPage.
3) If SkipMapping is not also specified, fvwm will switch to
the target desktop (if specified) and page (if specified),
except during initial startup, or during a Restart or
Recapture.
4) By default, StartsOnPage placement *does not* modify
USPosition, which means that apps started with a geometry
spec (and SkipMapping) will probably appear somewhere other
than the page you intended. This can be overridden by
specifying GlobalOpts StartsOnPageModifiesUSPosition.
5) ActivePlacement does not honor StartsOnPage (perhaps it should).
To Do:
------
1) SmartPlacementIsFiendishlyClever (see caveat below)
2) Decide whether this should be merged with StartsOnDesk or kept as
a separate Style. (Chuck - got any strong opinions on this?)
3) Decide which options to keep or remove. (Ibid.)
Caveats:
--------
1) There is one change in the behavior of StartsOnDesk: by
default, StartsOnDesk *no longer* moves a window back to its starting
desktop on a Restart/Recapture. (Initial capture on startup does
as it has always done.) If you dragged it to another desk, there it'll
stay, unless you override the default. (I think someone recently
expressed a wish for such a change.)
2) StartsOnPage in conjunction with SkipMapping introduces a
new, undocumented setting, SmartPlacementMaySeemCapricious. Until I
(or anyone who cares to volunteer) have some time to tinker with the
Smart/Clever placement code, a StartsOnPage window is positioned
within the target page at a spot appropriate for the page you're
currently on, not necessarily the one where it's about to be placed.
3) The name_list struct now carries the desk no. as 1-relative, not
0-relative, so 0 means "don't care", not "the first desk". It is
still stored 0-relative in the FvwmWindow struct, so most of Fvwm
is unaffected. If anyone knows of any module code that cares about
the internal Style representation of the desk no., please let me
know.
- Bob
"Never grep a yacc by the i-node."
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Sat Sep 20 1997 - 00:16:32 BST