Hi,
Thanks for your response, and sorry for my late reply.
On 2012-02-09 01:10:55+0000,
Thomas Adam <tho...@fvwm.org> wrote:
>
> > 14) Configuration GTK en su root.
>
> Eh?
>
Sorry, wrote this in the wrong file.
>
> > 24) I'm used to being able to click the root window to
> > unfocus windows, to remove the text cursor and prevent text
> > entry. It's mostly a tic, but I'd like to reproduce this in
> > FVWM, which by default, after having remove the left-click
> > root menu, does not unfocus windows at all when clicking
> > the root window.
>
> And?
>
Style Root NeverFocus?
>
> > 25) Why "Iconify", "Maximize", "Delete", etc., but
> > "WindowShade"?
>
> Eh?
>
WindowShade => Shade
>
> > As another example, in FvwmButtons, the manual says the
> > "Colorset" option only sets the background color... We have
> > to use the "Fore" option for the foreground, and apparently
> > it does not accept colorsets. Not only is this
> > inconsistent, but it also make us lose the benefit of
> > centralizing color definitions to easily change them...
>
> I think you've got your knickers in a twist here -- a defined
> colorset works fine in FvwmButtons.
>
In FvwmButtons manual of FVWM 2.6.4:
*FvwmButtons: Colorset colorset
Tells the module to use colorset colorset for the window
background. Refer to the FvwmTheme man page for details about
colorsets.
>
> > 41) I get this in my logs:
> >
> > FvwmIconMan: Bad line: *FvwmIconManUseWinList Yes
> > FvwmIconMan: What is this: Yes?
> >
> > - FvwmIconMan does not accept "Yes"/"yes"/"No"/"no" for
> > booleans values, contrary to the main FVWM
> > commands/options. It should, for consistency.
>
> Consistency with what?
>
Main FVWM manual, section 25. Boolean Arguments:
A number of commands take one or several boolean arguments.
These take a few equivalent inputs: "yes", "on", "true", "t"
and "y" all evaluate to true while "no", "off", "false", "f"
and "n" evaluate to false. [...]
>
> > 46) "*FvwmScript: Path $HOME/.fvwm/scripts" does not work.
> > "$HOME" is not expanded. Same with '~'. And it does not
> > accept quotes (they are included literally in the path).
>
> FVWM doesn't expand env vars like this, including "~", so why
> is it any different here, would you think?
>
Well it does for the Restart command (Main manual, 31.13.3),
but what I meant was that I wanted it to work.
>
> > options). Linking the concatenation of the
> > IconBox/IconGrid/IconFill (and IconSize?) options is an
> > abuse of the generic meaning of the syntax. Having a
> > backslash act the same as a command separator is even
> > worst. It also forces longer (and defining a multitude of
> > abbreviations for otherwise short commands like the
> > IconFill option is not a solution) and more complex lines.
>
> Are you mistaking the backslashes for readability in the man
> page?
>
Main FVWM manual: "A Style command with the IconBox option
replaces any icon box defined previously by another Style
command for the same style. Thats why the backslash in the
previous example is required".
If the meaning is "required if you want to split lines", then
it should be added to remove any possible confusion. (I'd like
to propose patches at least for these simple documentation
changes, but I do not have enough time, I just wrote problems I
encountered and suggestions I could make, like I do with many
other programs).
Bye.
--
Mathieu Bonnet <math...@kawagama.net>
