FVWM: Various notes on my experience with FVWM
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 c
Re: FVWM: Various notes on my experience with FVWM
On Thu, Feb 09, 2012 at 12:32:42AM +0100, Mathieu Bonnet wrote: > - MoveToDeskAndPage > - MoveAndGotoDesk, MoveAndGotoPage, MoveAndGotoDeskAndPage You can do these using a complex function, which I prefer in lieuof non-specific hard-coded commands in FVWM. > 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? Because EWMH is out-of-band to the original style options, but since EWMH_CMD_Style() receives the toggle flag "on" to indicate "!Foo" versus "Foo", it wouldn't be hard to do for this. > - 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). No -- simply retro-fitting negations to use !Foo which form negative negations, cannot work, and were not meant to work like this. So in introducing negations for EWMH-specific types, you'd need a little map to handle this and rename the option. > == > > 04) I'd say the default configuration should: http://article.gmane.org/gmane.comp.window-managers.fvwm/6611 > 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 No, because we look at Enter/Leave events in the pan windows which form the "edges" of the page. You could then further track MotionNotify events in this, but it's pointless and not well-defined. > 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? It's defined in ConfigFvwmDefaults, and staying there. Just like several other functions you won't have heard of, but provide functionality out of the box for you. > == > > 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. You miss the point of why I wrote "PrintInfo bindings", and see above. It's to provide minimal out-of-the-box configurations even when there's no default config and/or, that such a FVWM config either augments, or replaces that functionality found in ConfigFvwmDefaults. If you don't like something, change it. That's the way it works. > - 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. See above. > == > > 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. No, there should be no more Stays* commands, and everything should use numbers. > == > > 11) Why isn't WindowListFunc prefixed with 'Fvwm' like some > other builtin functions? I suppose I should use my own prefix Because there is no "standard" for this, and all FvwmFoo functions/menu definitions you've seen are examples. > (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. But see above -- namespacing is a more dangerous thing to suggest here, and I've yet to see *any* problems from not muddying the waters with this. > == > > 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 minimiz
Re: FVWM: Various notes on my experience with FVWM - iconbox
Mathieu Bonnet writes: > 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. Impressive job, thanks. > 57) Is it really necessary to allow multiple IconBox for the > same style? Even more than two? Yes, it was(is), since it's exactly what I wanted. (Yes, I am the guilty party, but it was on the TODO before I started.) I run icons down the right side of my screen below where the clock is. When I run out of room, I wanted control over where the overflow icons landed. In my case along the bottom of the screen moving from the right to the left. > (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. I'm lost. IconBoxes are styles and the default style is *. > - 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). Huh? You mean define box1, define box2 then have a style command refer to box1 and box2? Not sure I like that. > 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). Still lost. > - For more complex IconBox configurations, there is FvwmIconBox > anyway... Nope, no thanks. A window with a border that gets full and develops a scrollbar is nothing like icons on the root. > 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... Well, I probably wrote what has confused you. But I don't follow your change suggestions. > 59) The IconSize style option talks about padding and > clipping... Why would you not simply resize the icons...? Looks like I failed to properly review the IconSize modification. It's worse and better than you say. In Fvwm's current state, this command is valid: Style "*" IconBox -80 240 -1 -1, IconGrid 80 67, IconSize Adjusted 50 50 Other values are Stretched and Shrunk. > 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 u
