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 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. You can do this already, > > 13) ImagePath does not accept double quotes around the path > list. Yes it does. > ========== > > 14) Configuration GTK en su root. Eh? > ========== > > 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). No. These are being replaced slowly. > ========== > > 16) Rounded corners for window borders. From what I understand, In the future, yes. > 17) BorderStyle should accept more styles. For example, Solid, > instead of having to give a colorset. No. It's not a Decor. > ========== > > 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. Patches welcome to the documentation _only_. Why have you not also picked up on Colorset versus Colourset? > ========== > > 19) Apparently we cannot set different pixmaps for each border, > nor style the corners independently from the borders. What if I You can with a patch I wrote, but it's pointless adding it to FVWM now -- the decor code doesn't need it. > 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. No, X11 doesn't work like this. > ========== > > 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?). man FvwmTheme > - 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. No thanks. We've too many formats as it is. > ========== > > 23) If I use "TitleStyle Centered Height 16", the application > mini-icon is 12x12px instead of 16x16px (i.e., there is some Correct. The application sets this. > 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? > 25) Why "Iconify", "Maximize", "Delete", etc., but > "WindowShade"? Eh? > ========== > > 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. No, not it shouldn't. This is in the FVWM FAQ. > 28) Apparently "TitleStyle Colorset" only sets the background > color. For the foreground color, "Style * ForeColor" and > "HilightFore" color must be used. Use colorsets, please. > - Also, colorsets have a "Hilight" property, but it does not > differentiate between background and foreground. > > - More generally, colorsets seem underused. Yes. 2.6.X has only just gone stable. I am not expecting miracles from people upgrading from 2.4.X just yet. > 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. > 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 You can with InfoStore. > 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). Unless you send a patch for these, I'm not interested. > 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. Yes. There is no way to know in advance anything about the action a user might do to this, and I would not like to fool them by not changing the cursor. > 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. It's somewhat legacy, but still useful. I won't give you the long details, but it's to do with how the pallet of available colours an application can use, is allocated. > 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. Patch? > 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. Then you don't want to use a pager. You want to use FvwmEvent, and FvwmButtons. > - It would be useful for more complex designs like aligning > pages in diagonal or even in zig-zags. Really? Think about that a bit more, and then say it out loud to yourself. > ========== > > 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. History. Changing these is difficult. Seriously. > 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... Set the Padding and Frame options. > - 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. This is an X11-thing. So you can't. > 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. This is correct with respect to where the windows are, isn't it? > ========== > > 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. Maybe we could switch to window-specific bindings for FvwmPager, but we'd break the ability of FvwmPager to drag windows about, etc. Hmm, no, I think keeping it the way it is, might be best. > - Using "Action (Mouse 3) x" on the button, does not seem to > work/override the FvwmPager shortcuts. Correct. > 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" In context that's incorrect, because it's duplicated. > ========== > > 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? > - Why "Clic", and not "Click"? The author of it is French-speaking, obviously. > 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? > ========== > > 47) FvwmScript manual: "WindowTitle string" should be > "WindowTitle { string }". Syntax error otherwise. > > - Same for "WindowLocaleTitle string" I suppose. Again, patches? > 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. man FvwmWindowMenu > ========== > > 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. Yuck. > 53) FvwmIconMan: Apparently we cannot change the font depending > on the state of the window (e.g., bold font for the currently > focused window). Yes you can. > ========== > > 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. This would suck. No. > 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"? Look at the code in fvwm/style.c > - 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). Don't bother patching this -- is XML, and we're moving to Asciidoc. > ========== > > 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? No, they're two different things. > ========== > > 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 Yuck. > 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? > ========== > > 60) Why "FocusByProgram", but "AllowRestack" (instead of > "RaiseByProgram")? > > - Why are > "PassRaiseClick/AllowRaiseClickFunction/IgnoreRaiseClickMotion" > FocusStyle options, but "AllowRestack" is a normal Style option? AllowRestack has nothing to do with focus. > ========== > > 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. No, they come from Xlib. US == User-Specified. PS == Program-Specified. If you have to ask, you don't need them. > ========== > > 62) Why is "ResizeOpaque" a Style option, but "OpaqueMoveSize" > a command? Why the completely different syntax? XServer grabs, I suspect. > - Why not "Style * MoveOutline" instead of "OpaqueMoveSize 0"? No one's turned it into a per-window style option. > - FvwmSave vs. FvwmSaveDesk. Names are too close. Why the need Deprecated. > 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. In context, no. But if you compare an orange with another orange, you'll be OK with an orange. But compare and orange with a pumpkin, because both are orange, what do you get? > 68) We cannot read configuration files using jokers? ("Read Is this your English failing here? Only, this made me laugh. They're *wildcards* not Jokers. A Joker is something you get in a pack of cards. And you should use the term glob here, because that's what you're doing. > *.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. If you want to glob, fine. But that's your own doing, FVWM don't like it past ten iterations of "-c" anyway, and furthermore, your blind glob has no guarantee over the order of the files returned. So you're creating yourself more work like this. > 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. Write a function for this. > - 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. ... and exactly as it should be. > 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. IconBoxes house icons. The Icon style controls which, if any, get shown. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
