NOTICE: I am not subscribed to this list, so CC me if there is
a need for me to reply, and it does not take too much time. No
need to CC me for simple comments and status, I'll check the
web archive once in a while for some time.
Hi,
I started using FVWM around September 2011, and as I regularly
do, I wrote most problems I encountered, and suggestions I could
make. There are about 7000 words, for about 70 notes.
I suppose you know most of what I wrote already, some things may
only be confusion on my part (which may not be insignificant in
some cases though), and some others may have already been solved
since, but it's my experience with FVWM, and I hope there can
be some use for it :)
I was using FVWM 2.6.1 and 2.6.2 at the time (it is mostly a
September/October test, I couldn't find the time to continue
my configuration for now, but I'm using it now :)), under Gentoo
Linux.
Feel free to contact me if you need some clarification, if it
does not take too much time.
Thanks for FVWM,
Good luck in the future,
Bye!
PS: Don't mind the possibly directive tone in some notes, it's
mostly just terseness.
============================================================
01) New functions to implement by default:
- MoveToDeskAndPage
- MoveAndGotoDesk, MoveAndGotoPage, MoveAndGotoDeskAndPage
==========
02) I didn't find a way to concatenate commands (i.e., execute
multiple commands for like a keyboard shortcut or a menu
entry), and to specify user function arguments. We should not
need to use Perl or something else like this, for such
relatively simple features. It could avoid the need to create
user functions in the first case, and limit their number in the
second case (instead of having to define a function for each
possible argument).
- Ok actually we sure can use function arguments, so no problem
for this. The manual states, for the AddToFunc section: "There
is a number of predefined symbols that are replaced by certain
values if they appear on the command line. Please refer to the
Command Expansion section for details". Visibly, I didn't find
this clear enough. Now that I read more in detail, arguments
are also described in the examples under it. I'd say the
expression "function argument" or "function parameter" should
be in bold somewhere near the top of this section, probably
associated to the "predefined symbols" sentence, slightly
adjusted in consequence.
==========
03) Why "EWMHNoMiniIconOverride", and not
"!EWMHMiniIconOverride"? Is it still not deprecated? Will it be
in the future? (if not it should, for consistency). Does
"!EWMHMiniIconOverride" already works?
- Same for many options, it's not consistent, it's confusing.
- Even more confusing: "EWMHUseStrutHints" vs.
"EWMHIgnoreStrutHints".
- "DecorateTransient" vs. "NakedTransient".
- "BackingStore" vs. "BackingStoreOff" (vs.
"BackingStoreWindowDefault").
- "IconOverride" vs. "NoIconOverride" vs.
"NoActiveIconOverride" (apparently no "ActiveIconOverride"...
why a different name, if it is to prefix it with "No"?).
- Why "Style ** Icon unknown.xpm", and not simply "Style * Icon
unknown.xpm, NoIconOverride"? '**' is apparently used nowhere
else in this way... It complexifies the syntax...
- It's not even consistent for the same form of options... In
EWMH options, you already have "EWMHIgnoreWindowType" vs.
"!EWMHIgnoreWindowType"... (However you should really use
positive names, to avoid double-negatives, which are more
confusing... I suppose you used "Ignore", because the default
is not to ignore, to avoid having to use '!' symbols, but it
makes names inconsistent, and defaults can change -and AFAIC I
prefer to define most everything anyway, to be sure, so it
makes everything quite complex).
==========
04) I'd say the default configuration should:
- Use ClickToFocus.
- Allow resizing using the entire window borders and not just
their corners.
- Have nothing bound on Mouse 1 on the root window. The current
root menu would be rebound to Mouse 3, the current window list
on Mouse 3 would be rebound to Mouse 2. The current window ops
menu on Mouse 2 would be removed.
- Have various mouse and keyboard shortcuts to move between
desks and pages.
Like some combinations of Ctrl/Alt/Shift + arrows, to move
between pages, with or without the focused window. And Page
Up/Down instead of the arrows for desks.
- Obviously, to each his own, and obviously it is not meant to
be a stable configuration. But these changes would make it
significantly easier to start FVWM more rapidly, to continue
and finish our configuration, rather than either having to
spend days configuring FVWM from another window manager, or
suffering the various differences with "the more common
settings". MouseFocus and the left-click root menu easily make
every action dangerous. Missing the titlebar and clicking the
root window may mean closing FVWM. Forgetting to move the mouse
inside a window may mean deleting/adding some text to the
window below, with consequences which can easily be desastrous.
I understand some people may have gotten used to it, but it is
a very particular choice, and making it the default, notably
today, is simply a problem.
==========
05) Isn't there any way to EdgeResistance to switch desktop
pages with some pixel distance traveled outside the screen
area? A simple timer changes nothing to the problem of putting
the mouse in some corner quickly to get it out of the way,
leading to unwanted switches... If I had to actually travel a
few hundred pixels, it would limit this problems.
- If not possible (i.e., no way to record mouse movements in
the direction of the desktop page border, when already at the
desktop page border), at least some option so that, if the
mouse is not moving vertically on the left/right sides, or
horizontally on the top/bottom sides (i.e., perpendicular to
where we want to go, parallel to the screen side), after x
milliseconds from the time it entered the edge area of the
screen, desktop page switching is cancelled. That is, if I
throw my mouse to the side of my screen, and do not move it
anymore, there will be no switching. If I really want to
switch, I know I need to be sure to move my mouse a bit in the
edge area, perpendiculary to where I want to go, so that the
move can be registered and detected. And I suppose there is not
even to think about it, there will most likely be some
involuntary perpendicular movement. AFAIC, when I want to
switch, I generally often already have a clear diagonal
movement anyway.
==========
06) "Style * ResizeOpaque", but "OpaqueMoveSize unlimited"? No
transition to Style? Like "Style * MoveOpaque <max-size>". If
no argument, it would mean "unlimited".
==========
07) Some option so that "SnapAttraction" and "SnapGrid" apply
to resizing windows too. It is just as commonly needed as for
moving actions.
==========
08) Why is UrgencyFunc by default so pushy? Why is it filled
internally and not simply part of the default configuration
files generated when requested on first start, so we can easily
notice and adjust/remove it?
==========
09) Why are there internal default keyboard and mouse bindings?
Same as UrgencyFunc, they should all be defined in the default
configuration files generated when requested on first start, so
we can easily notice and adjust/remove them. This is a matter
of control and security in case you add any other internal
default bindings. And this is a matter of simplicity so we
don't have to find them all (`PrintInfo bindings`, manual, web
hoping it is updated) and reset them.
- If you are really worried about configuration mistakes making
us lose all access to FVWM commands, then at least provide some
option which would reset all builtin bindings easily, without
having to worry about future changes.
==========
10) There should be special keywords for the Layer command, for
the bottom/put/top layers as specified by the DefaultLayers
command. There should also be references to the Layer command
in the manual, from the DefaultLayers command section, and from
the StaysOnBottom, StaysPut, and StaysOnTop style descriptions.
==========
11) Why isn't WindowListFunc prefixed with 'Fvwm' like some
other builtin functions? I suppose I should use my own prefix
(but without namespace support, there is always a risk that a
simple prefix may be used some day), but mixing functions with
and without the 'Fvwm' prefix can be a bit confusing, and some
people may mistakenly override a builtin function, maybe losing
some functionality, or replacing them, with possible
control/security risks.
==========
12) I'd like to have an empty space on the right of window
titlebars, between the minimize/maximize buttons, and the close
button. I used an empty button with the Nop command, which is
visually ok although I would prefer full control of the space
to reduce it a bit, including in case I may want to add more
buttons there (like a sticky button on the left of the minimize
button, with yet another margin... I cannot even do it now
using an empty button, because it would require 6 buttons on
the right side). However, it still shows a hand when hovering
the area, which I would like to avoid.
- It would be nice to fully control the margin between these
buttons, and use the normal mouse cursor inside these spaces.
Probably set in the flag part of the ButtonStyle command.
Something like 'Margin 10' would add 10px to the left margin of
the left-side buttons, and 10px to the right margin of the
right-side buttons.
==========
13) ImagePath does not accept double quotes around the path
list.
==========
14) Configuration GTK en su root.
==========
15) "TitleStyle Centered Height 22", but "Style * BorderWidth
7, HandleWidth 7"? (there should be a BorderStyle alternative
syntax to specify these settings, like there is with
TitleStyle).
==========
16) Rounded corners for window borders. From what I understand,
we can use a transparent pixmap, but it requires enough
BorderWidth/HandleWidth for the actual corner. If I want a
1px-wide border, I could only remove 1px from the corners,
which is not enough. There should at least be some option to
have simple length-adjustable symmetric rounded corners for all
corners. The possibility to adjust their length independently
from each other would be useful in some cases (notably to
adjust the corners around the titlebar independently from the
two opposite ones). Asymmetric corners are probably far less
useful, but I suppose some people might want some, for specific
designs.
==========
17) BorderStyle should accept more styles. For example, Solid,
instead of having to give a colorset.
==========
18) Why is there a "Background" option for colorsets, but no
"Highlight" (only "Hilight")? It's even shorter by one
character... Also, "hilight" is used as a noun and verb all
through the manual, which from what I can see is an incorrect
usage.
==========
19) Apparently we cannot set different pixmaps for each border,
nor style the corners independently from the borders. What if I
want some horizontal texture for the horizontal borders, a
90°-rotated variation for the vertical borders, and some
adapted corners to join the two? Maybe even just 1px white, 2px
black, 1px white. The NoInset/Raised/Sunk flags do not give
good results for this, and I may want very specific colors.
Maybe at least some sort of SGradient which would only start
from the start of the border, and would not be stretched from a
square (i.e., you could set precisely the pixels for a thin
border).
- It could be useful to be able to specify different
BorderWidth/HandleWidth for each side too.
==========
20) I use flat borders and a flat titlebar, of the same color.
There should be an option to include a margin, between the
content of the window and the titlebar, of the same height of
the border, so that the titlebar buttons and title look
centered vertically in the titlebar area.
- The style of this margin would be configured like a border.
Some option to use the current border styles, and another one
to use the current titlebar style (in practice, in this case,
it would act as if it was an integral part of the titlebar).
- There is also the possibility of allowing us to adjust the
vertical alignment of the title in the titlebar, to center it
manually, but the possibility to configure the bottom of the
titlebar like a border would be nice, including to simply add
some 1px contrasting line to better separate it from the
content of the window.
==========
21) "Olive" is missing from my /usr/share/X11/rgb.txt. When set
as a background color with TitleStyle Inactive, through a
colorset, it leads to a black background. While this surely
should be the responsibility of Xorg maintainers, I suppose
that for some obscure matter, they still refuse to add it (they
have various color names containing "olive", and "olive" is an
HTML 3.2 and SVG color). It would be nice to include aliases
for all colors mentioned in HTML/CSS/SVG, which are not
included in Xorg, to avoid having to use RGB values.
==========
22) The rgb:XX/XX/XX format is used in examples in the manual,
but not explained independently, and there are apparently no
mention to the #XXXXXX format, which seems to be used by some
people, and I think I already tested it, although it sure is
not very good for it to use the '#' which is used for comments
in the file (even if maybe only at the beginning of lines
here?).
- Maybe an rgb:XXXXXX format should be supported too. It would
make it easier to copy-paste from and to other sources,
compared to the rgb:XX/XX/XX format.
==========
23) If I use "TitleStyle Centered Height 16", the application
mini-icon is 12x12px instead of 16x16px (i.e., there is some
margin we apparently cannot remove, which is reducing the icon
dimensions). There should be some option to adjust and remove
this margin, so that we can have a 16x16px titlebar without
reducing the icon dimensions. Same with all the titlebar
buttons I suppose.
==========
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.
- Currently, I use "Mouse 1 R A Focus", but while it does
remove the text cursor and prevent text entry, there are two
problems: it does not use the inactive window border/titlebar
styles, so visual feedback is limited, and it changes the mouse
cursor to a cross, which can catch the attention.
When clicking the root window twice, I get some brief HDD
and/or CPU noise, and the mouse cursor changes back to the
normal cursor. But the previously focused window still keeps
the active styles.
==========
25) Why "Iconify", "Maximize", "Delete", etc., but
"WindowShade"?
==========
26) I bound mouse buttons 6 to 9 to simple commands, and I get
on stderr things like:
[fvwm][ParseBinding]: <<WARNING>> Got mouse button 6 when the
maximum is 5. You can't bind complex functions to this button.
To suppress this warning, use: Silent Mouse 6 W 3 WindowShade
- FVWM should detect if it will work, and do not print a
warning. I don't want to clutter my session log file, and would
like to avoid using an additional keyword for no reason.
==========
27) In FvwmButtons, "ActiveColorset" when hovering, but for
commands like "ButtonStyle", "BorderStyle", etc., "Active"
means "pressed" ("PressColorset" in FvwmButtons).
==========
28) Apparently "TitleStyle Colorset" only sets the background
color. For the foreground color, "Style * ForeColor" and
"HilightFore" color must be used.
- Also, colorsets have a "Hilight" property, but it does not
differentiate between background and foreground.
- More generally, colorsets seem underused.
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...
Now that I read more and more of the different manuals and try
to find help from the web, I notice that there are multiple
cases of "commands vs. style instructions"... Sometimes
apparently the command is more basic, regarding colorsets, than
using a style instruction... It's quite confusing for
beginners, and can lead to quite a bit of wasted time. More
generally, it is quite messy in term of inheritance rules...
Apparently, if we specify one colorset, we cannot use
Back/Fore/etc. options in child contexts... For example, I use
the "Colorset" option of my FvwmButtons, and it renders the
"Back" option of each individual button useless, and I have to
define a colorset for each one...
It would be nice to be able to use names for colorsets, instead
of numbers. It would ease things a lot, when working on complex
configurations with a lot of modules and color variations
between modules.
==========
29) I noticed a few typos in the manuals. You should at least
use a spell checker to limit these (including FVWM keywords,
using a personal dictionary).
Some examples:
- Main manual: "What it should be understand".
"or that attepmts to become full screen but has
the." ("attempts", and unfinished sentence).
"NoUseUSPosition works like !UsePPosition but applies
suppresses using the user specified position indicated by the
program" ("applies suppresses"?).
- FvwmButtons manual: '$lleft' instead of '$left' (well this
one would still be noticed by a spell checker, and anyway you
could include all keywords in a personal dictionary to check
them too).
- FvwmPager manual: '*FvwmPager: Font font-name', then just
below 'If font_name is' ('-' vs. '_'). Same below for the
'SmallFont' option. Possibly elsewhere too.
==========
30) I use "Style FvwmButtons FixedSize, FixedPosition" for my
system panel, it does prevent resizing/movements, but the mouse
cursor still changes when hovering the border.
==========
31) I do not understand what the ColormapFocus does. The manual
says very little about it. Searching for "Colormap" leads us to
a large paragraph about color depth... If I understand it
correctly, considering I use a depth of 24 bits, I should not
care at all about this option? It should be written in the
description of the ColormapFocus command.
==========
32) In the default configuration, fvwm.buttons file:
# Show 5 more desks in a popup panel:
# Unfortunately, a popup shows the desks 1 to 5, then 0
- This comment is above the line for the task list. The popup
panel line is:
*FvwmButtons: (1x2, Panel(up, indicator, delay 5000, steps 5,
position Root 46 -108p) FvwmPagerSubPanel "Module FvwmPager
FvwmPagerSubPanel 1 5")
==========
33) FvwmButtons manual: the option following the "Legacy fields
[title icon command]" option is titled "The command", which can
leave us to think that the option is named "The", and that
"command" is a parameter.
==========
34) It seems to be quite complex to get pixel-precise results
with FvwmButtons... There should be a new BoxSize algorithm,
enabling us to specify the button geometry with pixel values
(relative to the inside of the FvwmButtons window), for all
buttons (including swallowed windows).
- For example, I'm swallowing an FvwmPager with one desk,
composed of three pages aligned horizontally. My screen
resolution is 1920x1200. My FvwmButtons is 1920x24. At first I
was using 14 columns (1 row) for the Buttons, so about 137px
per button. I had a menu button first, which effectively was
137px. But the Pager following it was limited to 36px, instead
of about 117px... I tried the "Size 117 24" option, but it does
not seem to work... I was using NoHints, I tried with Hints,
but it only add a vertical bar probably around the button
separation, without changing anything to the size of the pager.
I tried increasing the geometry of the pager to take two
buttons, and its width was doubled... but what was it taking as
a reference...? I tried setting my Buttons to 1920 columns, and
making the Pager 117 buttons wide, but it is still 36px... To
get around 117px, I have to make the Pager about 350 buttons
wide... It does work, but it is eating about 230 buttons more
than should be needed, which will likely cause me issues with
the rest of the Buttons... I can understand the original 36px,
considering FVWM considers pages as a virtual workspace, I
suppose it only takes into account the aspect ratio of the real
screen, so it squeezes my three pages into one screen
representation (of course it should not, but this is
understandable). But everything else is quite confusing. You
force using button geometry, but swallowed windows mostly
require pixel geometry, so they are quite hard to control with
the current button geometry...
If I don't specify "Columns 3" for the pager, it takes the
whole button, but I use pages completely independently from
each other, so I need a clear separation. It seems the
"Columns" option, beside the separation, is also dividing the
width by three, and requiring the use of three buttons to get
back to the width of one button... Really confusing and
erroneous.
Having said that, I checked on an empty desk for clarity, and
the separations are still there, so it should be alright I
suppose... So it would be specifying the columns manually, that
is causing issues with FvwmButtons?
==========
35) What if I want more separation between the different pages
of a swallowed FvwmPager? I may want to put each page in
different buttons, but the pager only allow to specify the
desks to show, not the pages... And I want to keep some
grouping, including for labels and easier keyboard shortcuts,
so I can't use 1x1 desks.
- It would be useful for more complex designs like aligning
pages in diagonal or even in zig-zags.
==========
36) There are regularly missing (and/or undocumented) options
and option values, corresponding to the default configuration.
I'd like to be able to specify everything, to avoid the risk of
changing defaults some day.
- For example, in the FvwmPanel manual: "*FvwmPager:
NoSeparators" and "*FvwmPager: SolidSeparators", but no
"DashedSeparators".
There are also many inconsistencies. In the example above, you
still use "No" in some modules at least, while in the main
manual all or most "No" are replaced with '!'. And why
different options instead of a single "Separator" option with
different possible values? This would also be easier to
document.
Of course this is a large project which evolved during a long
time, but it is currently quite messy, and it would be time for
a general cleanup, for the longer term. Of course there will be
some compatibility issues for some time, but if they are all
properly identified, in a dedicated document, with all version
numbers, I suppose this won't be too problematic, as long as
these changes are limited in time.
==========
37) I swallowed an FvwmPager in an FvwmButtons. There is a 1px
black line on the right of the pager, but not on the left, nor
on top or bottom. It does not appear if I make the pager
wider...
- If using dashed separators, I'd like to be able to control
the size/spacing of the dashes. I use it in a 24px-high
taskbar, so the current large dashes are not aesthetic.
I would also like to specify some page padding, so windows are
not stuck to the external borders of the pager, nor to the
separator lines. Currently the windows even overlap the
separation, which is apparently counted in the desk space.
==========
38) I would like to rebind the mouse shortcuts for FvwmPager
(e.g., removing the mouse 2 and 3 actions, and using mouse 3 to
open a panel of the swallowing FvwmButtons, adding a shortcut
to switch page using the mouse wheel when in the pager area,
adding a right-click menu with various stuffs like iconify all,
close all, etc.). Of course I can add a dedicated button, but
it could be avoidable.
- Using "Action (Mouse 3) x" on the button, does not seem to
work/override the FvwmPager shortcuts.
==========
39) FvwmIconMan manual: why "ShowOnlyIcons", but "ShowNoIcons",
which should be, from the description, "ShowOnlyNoIcons", or
"ShowOnlyNotIconified", or something like this.
==========
40) FvwmIconMan manual: In the "ACTIONS" section, it says "The
syntax for actions are: Key actions: Key Keysym Modifiers
FunctionList". Yet the complete syntax, as I understand from
the beginning of the manual, is: "*FvwmIconMan: [id] Action Key
Keysym Modifiers FunctionList"
==========
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.
==========
42) I use "*FvwmIconMan: ButtonGeometry 320x24". The text is
not centered vertically with the default fond. It is 1-2px too
low. I suppose setting a slightly larger font helps, but it
should really be centered.
==========
43) FvwmScript: I'd like a rotate property for the ItemDraw
widget. At least +/- 90°, for vertical text.
==========
44) FvwmScript manual: on multiple occasion, you say things
like "ChangeTitle id1 id2 - Set the title of the widget
numbered id1 to id2". But "id2" is not a widget identifier, it
is a variable or I suppose maybe directly a string. It can be a
bit confusing.
==========
45) FvwmScript manual: The "SingleClic" is not documented
independently from examples. At first I thought it was a simple
event name example, which we had to transmit ourselves, but it
is apparently actually standardized.
- Why "Clic", and not "Click"?
- There is a "Key" instruction, but not a "Mouse" instruction,
to bind mouse buttons independently and generate custom events?
It would very useful.
==========
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).
==========
47) FvwmScript manual: "WindowTitle string" should be
"WindowTitle { string }". Syntax error otherwise.
- Same for "WindowLocaleTitle string" I suppose.
==========
48) FvwmScript manual: There is apparently no mention of the
Main part of a widget definition being necessary. If I don't
put it, my script will work, but there will be a "syntax error"
message.
- It should not be required.
- Note that not only the "Main End" part is required, but also
either the "Case message of SingleClic: Begin End" event loop,
or maybe at least one event loop, I didnt't test.
By the way, the "Case message of\nEventName:" syntax is
bizarre. I understand this could be considered as "minor as
long as it works", but if someday you update other syntax
elements, breaking compatibility, it should be changed too, to
something like "Event EventName".
"Init" vs. "PeriodicTasks" vs. "QuitFunc". Should be something
like "Init", "Loop", "Quit".
Of course, if you care, temporary aliases could be used, with
enough warning and time before removing the original syntax...
==========
49) FvwmScript: I have a script invoking 'date' every seconds,
updating an ItemDraw... But in practice, it updates only every
two seconds, and it flickers every few updates, sometimes every
second for a few times...
- From some posts in
http://www.fvwmforums.org/phpBB3/viewtopic.php?f=7&t=959 the
flickering seems to be due to TTF fonts. Would be nice to avoid
having to use bitmap fonts or split the widgets so only the
seconds flicker...
I used a bitmap font
(-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1),
and it stills very occasionally flickers (tolerable, but really
should never be there...).
==========
50) FvwmScript: GetOutput should accept word ranges (and words
should be defined precisely -and it would be useful to be able
to change this definition whenever we want).
- And there should be StrCopy-equivalent working with words
instead of characters.
==========
51) WindowList command: I want to be able to specify the exact
format. I notably want to include the class of the window
first, as many applications only show it at the end, if at all,
and relying on icons is not enough.
==========
52) In a button of an FvwmButtons, I use an icon which is
really a picture of a button, as I don't want to use the FVWM
button style. I'd like to avoid having to include the text of
the button inside the picture, but there is apparently no way
to overlay the title above the icon. It is either under or on
the side of it. There should be an option to overlay the two.
==========
53) FvwmIconMan: Apparently we cannot change the font depending
on the state of the window (e.g., bold font for the currently
focused window).
==========
54) Functions can detect double-clicks, but triple-clicks can
also be useful sometimes, and not too difficult to do. XTerm,
for example, allows up to five clicks, for different selections.
- It would be nice to be able to bind multiple clicks directly
with the Mouse command too.
==========
55) FVWM main manual: In a paragraph like: "NoUsePPosition
instructs fvwm to ignore the program specified position
(PPosition hint) when adding new windows. Using PPosition is
required for some applications, but if you do not have one of
those it's a real headache. Many programs set PPosition to
something obnoxious like 0,0 (upper left corner).
Note: !UsePPosition is equivalent to the deprecated option
NoPPosition", what is the actual command to use to allow
PPosition? "!NoUsePPosition"? "PPosition"? "UsePPosition"? Why
is "NoPPosition" deprecated, but not "NoUsePPosition"?
- And the "NoUsePPosition" option at the beginning of the
paragraph is not in italic (same for a lot of other options in
the manual)... I'd say commands and options should even be in
bold, to notice them really easily, when they have no link to
their definition already. Although not sufficient for
accessibility, they should also use different colors (one for
commands, one for options).
==========
56) FVWM main manual: "An IconGrid/IconFill definition must
follow the IconBox definition that it applies to", but no
mention of this for IconSize... Can it be IconBox-specific too?
==========
57) Is it really necessary to allow multiple IconBox for the
same style? Even more than two? (if not, you could have
DefaultIconBox/DefaultIconGrid/DefaultIconFill/DefaultIconSize
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.
- If really you want to allow more than two IconBox per style,
there should at least be a dedicated option grouping all these
options, and even then this would be inconsistent with the
generic overriding meaning of using the same option multiple
times (and effectively renders overriding impossible).
The only real solution would be to use dedicated commands,
similarly to how it is handled with ButtonStyle commands
(ButtonStyle, ButtonStyle Reset, AddButtonStyle). Style options
could be kept, but would use the generic meaning of the Style
syntax, meaning we could only define a single IconBox per style
(or two, if you add the DefaultIcon* options mentionned above).
- For more complex IconBox configurations, there is FvwmIconBox
anyway...
==========
58) The IconFill style option uses a "gravity origin" direction
system (i.e., you have to indicate where is the gravity source,
and it starts filling there, so the following icons are put
where there is place left the closest of the gravity source,
but somehow filling up some rows/columns first depending on the
order of the coordinates of a fixed point...), which is very
confusing. It is a clunky and useless metaphor. Some other
programs use it (e.g., StaloneTray), I don't know if there is
any reference to it in X11 documentation for anything, but this
is not a reason, in any case. You should use a simple
directional system: the icons are filled going to the specified
directions. If I want filling from left to right, I specify
right.
- Wait... my icons are actually filled from the point
specified, instead of using it as a direction as specified in
the manual: "using these arguments to control the direction the
box is filled in"... and the example uses "IconFill Bottom
Right", which, with this understanding, seems to be the most
classical use (having the icons in the top left of the screen,
and having them be filled from top to bottom, and left to
right)...
Wait again... "IconFill Bottom Right" is not an example, but a
specification... "Bottom" and "Right" are not meant to be
actual locations/directions, but the name of the arguments...
it is very confusing to name them the same as actual values...
(they should be named something like "Vertical-Direction" and
"Horizontal-Direction").
Alright, so you actually say after this: "By default the
direction is left to right, then top to bottom. This would be
expressed as: IconFill left top"... I think I remember I
actually read this part too, but this was globally so confusing
that I held to the first thing I thought I understood, that is
what seems to be meaning of the first part of the
explainations...
==========
59) The IconSize style option talks about padding and
clipping... Why would you not simply resize the icons...?
==========
60) Why "FocusByProgram", but "AllowRestack" (instead of
"RaiseByProgram")?
- Why are
"PassRaiseClick/AllowRaiseClickFunction/IgnoreRaiseClickMotion"
FocusStyle options, but "AllowRestack" is a normal Style option?
==========
61) FVWM main manual: "FixedPosition and FixedUSPosition make
fvwm ignore attempts of the user to move the window". What's
the difference? Same for the other functions below. From the
NoUsePPosition option documentation, "US" means "User" (not
very good to use all caps, and an abbreviation, here, but camel
case and full names for the other words), but there are the
"FixedPPosition" and "FixedPSize" for programs... so they are
really only simple aliases? They should be avoided.
==========
62) Why is "ResizeOpaque" a Style option, but "OpaqueMoveSize"
a command? Why the completely different syntax?
- Why not "Style * MoveOutline" instead of "OpaqueMoveSize 0"?
- Why "OpaqueMoveSize unlimited" or "OpaqueMoveSize -1", while
some other commands only accept "-1" without a keyword (e.g.,
"EdgeResistance -1"... why not "EdgeResistance infinite", or
something like this?). Why no keyword for other particular
values? "-1" often means nothing outside of the programmer's
point of view. Using many keywords can be a bit more complex,
notably to be precise (instead of using too many generic words
which may bit apply very well to each case), but as long as it
properly documented, and limited to real need, it can be very
clear.
==========
63) There should be more precise suggestions for each modules.
- For example, in the FvwmTaskbar manual, "DESCRIPTION"
section, there should be a prominent note about the fact this
module is relatively basic, that (from what I read on the web)
it is relatively unmaintained, and that, while a bit more
difficult and long, FvwmButtons + FvwmIconMan (along with a few
other modules, like FvwmPager) should be used.
Same for FvwmWinList vs FvwmIconMan I think I remember.
Personally, I would even deprecate FvwmTaskbar and FvwmWinList,
if mostly unmaintained... Of course not suddenly, but the
manual should write in big bold letters at the top "DEPRECATED:
This module is deprecated. It will only be minimally maintained
until 2012-12-31, then removed. You should migrate to using
FvwmButtons + FvwmIconMan", then giving them some link to a
default configuration using FvwmButtons + FvwmIconMan in a
similar arrangement to the current FvwmTaskBar module, with
enough comments in the file, and that should be far enough.
It's not that much complex to configure.
- FvwmIconBox vs. FvwmIconMan vs. FvwmWinList vs. FvwmTaskBar
vs. FvwmButtons... Not clear enough when we do not know about
them... The "DESCRIPTION" section should have at least one
clearer sentence summarizing their functions in more "common"
terms (i.e., to be clear, for people coming from Windows, and
even X11 WMs not as featurefull as FVWM).
For example, for FvwmIconBox, there should be a mention to the
fact we are talking about running minimized window icons (i.e.,
not launcher icons), and that an FvwmIconBox is effectively a
configurable frame to show and control all or part of these
icons.
For FvwmIconMan, there should be a mention to the list of
current windows as in a taskbar (the only mention to it relates
to label width, which is secondary), although far more
configurable in many ways.
For FvwmButtons, there should be a mention to the idea this
"window of buttons" is a fully configurable panel (as with
FvwmIconMan, you do mention panels, but only relating to a
secondary feature... it's like describing a car with all sort
of complex and unusual qualificatives keeping people guessing,
then saying it has wheels, and then everyone exclaims: "Ah! We
were talking about some sort of vehicule!"...).
- FvwmSave vs. FvwmSaveDesk. Names are too close. Why the need
for these two? And in none of the two manuals for these
commands is there any mention to the "session" expression,
which is the common name for what I suppose these two modules
are doing.
==========
64) fvwm.iconbox default configuration file, regarding the
comment 'Note that icons are shown in the module ONLY if NoIcon
commnand is applied. Style "*" NoIcon':
- "NoIcon" is not a command, but a style option.
- There should be a mention to the fact we are talking about
internal IconBox vs. FvwmIconBox module. The style option
deactivates the internal icon boxes, which enables the
possibility to use FvwmIconBox (otherwise disabled, to avoid
listing icons twice, in different boxes). Currently it feels
like "Huh? We have to deactivate icons to show icons? Is that
just very bad and unintuitive naming of sort? What am I missing
here?".
==========
65) FvwmScroll manual: "An integer followed by a p describe a
size as a percentage".
- Fvwm main manual, about the Menu command: "Furthermore a
trailing 'p' changes the interpretation to mean pixels"...
- Inconsistent, confusing.
==========
66) fvwm.scroll default configuration files contains a "Fore"
property, but in the FvwmScroll manual, only "Colorset" and
"Back" are defined.
- And for "Back", it talks about the window background? I
suppose this relates to the scrollbar color...
==========
67) FvwmScroll manual: "integers immediately followed by a p",
"p" should use single quotes at least.
- "An integer describe a size reduction"... What's a "size
reduction"? How do I write it? "50" for "50%"? or "0.5"? or "2"?
==========
68) We cannot read configuration files using jokers? ("Read
*.conf"). I like split files. I can list the main configuration
files, but I'd like to use a joker for a style subdirectory
containing one file per application I want to customize.
==========
69) I use a UTF-8 locale, it works everywhere. Why do I have to
add "encoding=ISO10646-1" (Xft) to my font references manually?
(e.g., "DejaVu Sans", and various others, which is never needed
in any other program I use with these fonts). Why doesn't
"encoding=UTF-8" works? (using "StringEncoding=UTF-8" instead
does not seem to work, the Unicode characters are still
displayed as latin1-like giberish, instead of the one missing
glyph rectangle per Unicode character I get using
"encoding=ISO10646-1").
- Why doesn't FVWM substitute font when a glyph is not found,
like most programs (at the very least, all GTK programs I
know)? I know I should define a dedicated virtual font myself
for this, so Xft handles it by itself, but if it's not too
complex, FVWM should fallback to sans-serif/serif/monospace,
depending on the type of the font specified, if a glyph is
missing.
Well, specifying "sans-serif" (which I should have properly
configured with various fonts) does not seem to work either, so
there may be other problems... I also tried a custom virtual
font name, apparently without change.
- Said otherwise, I want to use "DejaVu Sans" as my main font
for everything it can display, most notably latin scripts, but
it does not support Japanese characters, and I want to use
"Sazanami Gothic" for these. All in UTF-8. I can get either to
work, but if I use a virtual font which specifies both, only
"DejaVu Sans" (the first font) is used, and Japanese characters
are displayed as missing glyph rectangles.
Another problem is that I use "style=Bold" with "Sazanami
Gothic", but it does not show as bold. I do suppose the font
does not support it, but Firefox, for example, simulates a bold
weight if not supported by the font. Well, I probably won't use
it anyway, because it is only readable for kanas and not for
kanji at this size, but may still be useful in some cases.
==========
70) I use: "Style * SnapAttraction 16 SameType ScreenAll" and
"Style * SnapGrid 8 8" (with a 1920x1200 resolution), but I
regularly have some windows which end up like 1px too low, so
when I move my mouse quickly to the top of my screen to select
it, I end up clicking the root window (or some other window
under the application if I had one), thus not changing the
focus, and if I use some keyboard shortcut without noticing, it
can lead to important problems. I'm not sure how it happens
precisely. I notice it most often with Firefox, because of its
location on my desktop and the regular need to select it
through its titlebar to avoid clicking on buttons/links in the
content by error, but I think it happens with various other
windows too.
- If the specific cause cannot be found, it could be useful to
have an option so that any window placed manually/automatically
a few pixels from a screen border (configurable, and by default
probably no more than half the default titlebar+border height,
so people cascading windows do not have any issue with it), are
systematically and immediately moved precisely to the screen
border.
- I thought about MoveThreshold, but I didn't set it, so it
should be the 3px default... I wouldn't think I move my mouse
this much, this commonly, when clicking on window titlebars to
focus them... Well, I'll try increasing it a bit more, although
I don't like the idea losing immediate dragging precision...
There should probably at least be some option to limit this to
focusing/raising clicks...
==========
71) Option for per-page focus, so we don't risk doing things in
an application we do not see, and so we don't have to focus
back applications everytime we do something in another page.
- Another issue with the normal behavior of pages, is that even
with page switching deactivated, when an application creates a
window leaking maybe more than 50% to another page (or we move
it similarly), and we focus it, we are switched to the other
page, which is most confusing, frustrating, and anti-usable.
- I want to use your two-level workspace system for easier
pager management (e.g., showing the current desk in a taskbar
pager, with three pages, simply by calling the pager with
"Module FvwmPager *"), and easier navigation using a 2D space
(Win+Left/Right for pages, Win+Top/Bottom for desks), instead
of a single row or line of desks (of course I still could
implement the 2D space with only desks, but this would require
much more work), considering I need 18 pages (6 desks of 3
pages), but it is apparently difficult, if not impossible, to
make pages behave more like independent desks, except for the
pager and shortcuts.
==========
72) I have 4px window borders. If I click on a pixel closer to
the content to resize the window to a page/screen border, it
will hide all or part of the window border outside the
page/screen, which is not clean. It should probably not be
possible. It goes with the snapping option suggestion for
resizing windows.
- If using diagonal resizing, and clicking farther below, on a
side, it can even hide the titlebar almost completely... (same
for status bars on the bottom). I don't want having the be
precise when resizing. And I don't want having to move the
window for snapping, after each resize...
==========
73) I'm using "Style * IconBox none", without any other IconBox
style definitions, nor any use of FvwmIconBox, yet, after even
a complete FVWM restart (I mean computer restart in-between),
when I iconify windows, they still show as icons on my
workspace. As I'm using a taskbar, I don't want icons at all on
my desktop (catches the attention, risks of clicking on them
when trying to unfocus a window, etc.). Nothing about icons in
my session log.
============================================================
--
Mathieu Bonnet <math...@kawagama.net>
