Mathieu Bonnet <math...@kawagama.net> 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 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. Yes, there is a default built in iconbox that you cannot remove. On purpose. With Fvwm you get the core and modules are free to do what they want. The core of Fvwm uses the iconbox to represent minimized applications. If you want some module to take over you should tell fvwm you want "Style * NoIcon". Some time in the future I'll try to update the docs for iconbox. Thanks again. -- Dan Espen
