Thomas Adam wrote:
> On Wed, Aug 11, 2010 at 04:19:20PM +0200, Michael Großer wrote:
>> 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/[email protected]/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.
>
> I started this for FvwmEvent -- you can see the changes to the manpage here:
>
> http://github.com/ThomasAdam/fvwm/commit/49a53ee408cba26f7649fc4b56df0d309b485cfd
>
> Run that file through "man" -- see the table produced. Is that what you
> were after?
>
> -- Thomas Adam
>
I cannot find any displayable man page.
But, I found some kind of source file named "FvwmEvent.1.in".
There, I found:
> T{
> destroy_window
> T}
> @T{
> Runs when a window is closed.
> T}
> _
Yes. This is a good start. Now, the reader is not
guessing but reading and knowing. There is difference between
the one case, where the reader guesses and the other case,
where the reader knows the facts because they are written
down by the author.
> T{
> res_class
> T}
> @T{
> Runs when the WM_CLASS property of a window changes.
> T}
> _
> T{
> res_name
> T}
> @T{
> Runs when the WM_CLASS property of a window changes (for the resource).
> T}
> _
Are you sure that a WM_CLASS property causes both the res_class
and the res_name event? I don't know so much about this WM_XXX stuff,
but if I think logically, shouldn't it mean WM_NAME in the
second event? If not, what is the difference between
res_class and res_name? Why two events have to exist? Why
not one? Or is one of them an alias of the other?
Michael
