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/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.
Well, nothing generates these events from FvwmEvent's point of view -- FvwmEvent will just react to events -- but I take your point, they could be explained better. > 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. That's a CSS issue only from the resulting HTML output. The documentation itself is single-sourced in a monstrous mess of docbook XML (which **will** be changing in 2.6.0 -- it's just fucking abysmal to keep it the way it is for much longer. That's a promise) -- so what we change will affect not only the HTML, but the man page as well. > 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) Yes. OK. Point taken. Shouldn't be too difficult to do. > 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. Tables I think. They translate into groff much easier. > It could help to keep the orange color of the > letters because the more color, the more eye catching > is the relevant information. In terms of HTML, yes. That won't change, but manpages are a different kettle of fish. > * context > * modifiers > * focus policies OK. No problems. I will look at this later on when I get back from work. -- Thomas Adam
