Hi,
Sorry for the late reply.
On 2012-02-08 22:27:34-0500,
Dan Espen <des...@verizon.net> wrote:
>
> > 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 *.
>
What I meant was that if you only need two main IconBox (a
normal area, and an overflow area, like in your case), there
could a new style to define the overflow area, instead of
having to concatenate the IconBox definitions using a
backslash (which usually only means breaking a line in two
parts).
"Default" may indeed be confusing though... Using "Overflow"
would probably be clearer.
That is:
Style * IconBox l t r b
Style * OverflowIconBox l t r b
And then there is the problem of the different meaning of
the comma concatenation of IconBox/IconGrid/IconFill.
The normal syntax says that the comma is simply used to
concatenate style options, processed in order, at the same
hierarchical level, meaning that if specifying the same style
twice, only the second definition will be taken into account.
Here, you use the comma to mean the properties are linked
together, and do not override other similar definitions.
The solution, if two IconBox are enough (I sure can imagine
people with thirty applications with icons all around the
screen, but is this really necessary, knowing that FvwmIconBox
can be used for these more complex and exceptional setups?),
would be to only allow two IconBox per style, and have
different names for them. We would get rid of the syntax abuses
of the comma and slash character.
>
> > - 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.
>
I meant something like:
Style * IconBox l t r b fill-left fill-top grid-x grid-y,\
IconBox l t r b fill-left fill-top grid-x grid-y
Well, doesn't solve much anything, but still a bit easier than
repeating multiple IconBox/IconFill/IconGrid series, although
long lists of unnamed parameters sure are a problem...
Anyway, I was just noting the abuse of syntax, which can be
confusing. Of course in itself this is rather trivial, but the
less the better.
>
> > 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.
>
IconBox * l t r b fill-left fill-top grid-x grid-y
AddIconBox * l t r b fill-left fill-top grid-x grid-y
AddIconBox * l t r b fill-left fill-top grid-x grid-y
IconBox * Reset
>
> > - 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.
>
Seems it would be better to extend the more developed module
with options to control this, rather than trying to complexify
the more simple core options...
>
> > 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.
>
To summarize:
- To have the icons filled from left to right, and from top to
bottom, we currently have to specify "IconFill left top".
Specifying a direction, instead of an origin, would be far more
intuitive (although of course changing it now will be a
problem, again I was just noting it).
- The manual defines the syntax as: "IconFill Bottom Right".
With the above change, it should be changed to something like
"IconFill <VerticalDirection> <HorizontalDirection>" (well, you
use an italic style in the manual for parameter names, but it
can be confusing...).
Thanks for your reply,
Bye.
--
Mathieu Bonnet <math...@kawagama.net>
