On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote: > Thomas Adam wrote: > > On Wed, Aug 11, 2010 at 01:23:43PM +0200, Michael Großer wrote: > >> space for all my different projects. I configured > >> a lot of bindings so I can use the keyboard to > >> create new windows or operate with the viewports. > >> I studied the sample config files of the fvwm95 > >> project to get suggestions. I created a digital > > > > Why? You won't learn anything from looking at that file -- it's very old. > > To get a clue how things work. The man pages > have the theory and the fvwm95 config files > contain the practice and can immediately be > tested. In other words: The man pages are the > reference and the fvwm95 config files are an > example. But 90 percent of my own config files > is code that I checked against the man pages, > because I actually want to understand my > own code.
Sure -- and it's not your fault, it's just that to solve this "problem" properly, requires a lot more effort/changes than simply updating the config file to reflect newer changes in syntax, etc. That has only been half-heartedly done recently -- there's a lot of crap still in there which either needs to be removed, or updated. Note that I am not talking about the fvwm95 example file specifically, but about the config files installed via FvwmFormSetup. That's a big contention point historically in FVWM though. :) > Some examples: > > 1. FuncFvwmRaiseLowerX > ====================== > This page... > http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html > ... does not explain, how FuncFvwmRaiseLowerX exactly > works. I just use it and I don't understand it. > I just use it to move windows with > "Win" + "left mouse button" and it does the > job for me. I don't now why. This could be > improved. Perhaps just make a link to the > document that gives more information about > FuncFvwmRaiseLowerX. By default, it looks like this: AddToFunc FuncFvwmRaiseLowerX + I Raise + M $0 + D Lower And is invoked (by default) like this: Mouse 1 T A FuncFvwmRaiseLowerX Move Mouse 1 FS A FuncFvwmRaiseLowerX Resize Mouse 2 FST A FuncFvwmRaiseLowerX Move Hence, what this function does is wrap two similar functionalities together. * Whenever the function is run on a window (+ I) it's raised -- always. * If the window is moved (+M) then the action passed into that function is called -- so in the above example, we have a choice of either "Move" or "Resize" depending on the binding. * If the user double-clicks (either on the Title (T), Frames (F) or Sides (S), then the window is lowered. In the link to the fvwmwiki article I gave you, I explain where this function is defined, and why it's not "accessible" to the user, and why they have to redefine it for themselves. But I take your point that there is little documentation on what the function does, but its definition is in "man fvwm". I will look at improving this later on this evening. > 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? > 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. You are aware we have HTML documentation which fragments the monolithic manpage, right? http://fvwm.org/doc/unstable/index.html > 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. 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
