Thomas Adam wrote:
> On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote:
>
>> 2. destroy_window
>> =================
>> This page...
>> http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php
>> ... mentions "destroy_window" only two times.
>> I can guess what it does, and I think, I will
>> solve my problems with this, but one little section
>> for each event that explains what exactly causes
>> the respective event, would be a nice improvement.
>
> Note also -- there is this rather idiotic thread:
>
> http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html
>
> But take away from that post that some of the information you're wanting --
> whilst useful -- might be adding bloat. In your case, are you saying for
> FvwmEvent you want an explanation of what each event does, and when it's
> triggered? I could add that, but assumed the names themselves are
> self-documenting.
>
> Again -- can you provide an example using "destroy_window" what sort of
> information you're wanting to see?
Such kind of information could be nice:
- destroy_window:
--> Generates an event if a window disappears.
- res_class:
--> What exactly causes this event?
(I don't know)
- res_name:
--> What exactly causes this event?
(I don't know)
So, a list would be fine that mentions
this kind of information:
- event name
- what exactly causes the event
- event name
- what exactly causes the event
- event name
- what exactly causes the event
- ...
- ...
- ...
- and so on
>
>> 3. continuous text
>> ==================
>> The human race is an image processing animal.
>> When I was studying the bindings syntax, I needed
>> a reference. I needed the particular options
>> in tables. But, I found them amongst continuous text.
>> The first thing that I did was creating my own
>> reference (half German, half English) that
>> I attached to this e-mail message.
>
> I am *especially* keen on this sort of information because of the impending
> 2.6.0 release. I have no problems delaying FVWM further if this sort of
> thing is going to be useful; *but* making the data tabular also might lose
> readability in things like man page formats.
Give it a try.
>
> You are aware we have HTML documentation which fragments the monolithic
> manpage, right?
>
> http://fvwm.org/doc/unstable/index.html
Now, I am ware of this, beaus you pointed this out ;-)
>> Just look at the attachments to guess what I mean.
>
> Sorry, I don't speak German. But if you can be more specific about which
> areas you think would benefit from tabulating information, I am happy to
> work with you to accomplish this.
Look at this:
http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html#menus
31.1.13. Menu
The orange color of the headwords and then the documentation
in black color is a good start.
Now, look here:
http://fvwm.org/doc/unstable/commands/Mouse.html
Read this text:
> Context describes where the binding applies. Valid
> contexts are 'R' for the root window, 'W' for an
> application window, 'D' for a desktop application
> (as kdesktop or Nautilus desktop), 'T' for a window
> title-bar, 'S' for a window side, top, or bottom bar,
> '[', ']', '-' and '_' for the left, right, top or
> bottom side only, 'F' for a window frame (the corners),
> '<', '^', '>' and 'v' for the top left, top right,
> bottom right or bottom left corner, 'I' for an icon
> window, or '0' through '9' for title-bar buttons,
> or any combination of these letters. 'A' is for
> any context. For instance, a context of "FST"
> applies when the mouse is anywhere in a window's
> border except the title-bar buttons. Only 'S' and
> 'W' are valid for an undecorated window.
Now, read this text:
Context
-------
It describes where the binding applies. Valid contexts are:
- 'R' for the root window
- 'W' for an application window
- 'D' for a desktop application (as kdesktop or Nautilus
desktop)
- 'T' for a window title-bar
- 'S' for a window side, top, or bottom bar
- '[' the left bottom side only
- ']' the right side only
- '-' the top side only
- '_' the bottom side only
- 'F' for a window frame (the corners)
- '<' for the top left corner
- '^' for the top corner
- '>' for the top bottom right corner
- 'v' for the top bottom left corner
- 'I' for an icon window
- '0' through '9' for title-bar buttons
- any combination of these letters are possible too
- 'A' is for any context
Example
-------
A context of "FST" applies when the mouse is anywhere in
a window's border except the title-bar buttons.
Only 'S' and 'W' are valid for an undecorated window.
I quickly hacked my version of the text just now, but
perhaps you could see that now it is a lot easier
to read my version of the text. Give it a further
improve and as the result you should have a text
that suits both HTML pages and classic man pages.
For this hack, I chose the list form. The
table form would also be good idea. It doesn't
matter if you choose the list form or the table
form as long as you break up this continuous text
form that is hard to read.
It could help to keep the orange color of the
letters because the more color, the more eye catching
is the relevant information.
At least the following pieces of information
should be treated like I shown above:
* context
* modifiers
* focus policies
... and some more essential keywords that are
enclosed in continuous text but could better
be listed as I showed above.
> I've been banging on for *years* about this sort of thing, and finally it
> might actually happen. :)
>
> You've made my day. :)
>
> -- Thomas Adam
>
It was not my intention to start such a big wave.
It just happened :-)
Michael
