On Sun, Jun 13, 2010 at 09:58:56PM -0400, des...@verizon.net wrote: > Thomas Adam <tho...@xteddy.org> writes: > > 2. Perhaps more importantly, we have a number of users who compile FVWM up > > themselves, or we have environments where FVWM is deployed in rather > > interesting circumstances (perhaps you've alluded to one below, in your > > deployment scenario?) -- out-of-the-box, FVWM won't "work", due to these > > external dependencies not being part of most base-perl installs. It was OK > > for FvwmTabs, that has a handy TK dialogue to tell you as such -- but for > > a script a number of people are using, and *will* be using, it's slightly > > frustrating. > > Pretty much agree but XML parsing from Perl isn't that rare. > Especially for users that will want auto generated menus. > As long as it's an optional feature, I think it's okay.
Well, the script's use itself is optional, yes. But the dependencies it relies on obviously cannot be. :) > > If you or *anyone* else wanted to actually help, by all means look at > > writing more purify tests -- that alone would likely throw up some > > interesting bugs if they were structured properly -- I have several ideas on > > how to improve these tests, so if anyone is seriously interested, do please > > ask me! > > As I remember, Dominik created the tests and I took one pass thru the > man pages vs. the tests. It was a horrible, boring experience, one I > never wanted to repeat again. Well I for one am very appreciative we have at least that -- even if it was all those years ago. Thanks. :) > I thought maybe we could come up with a scheme were when a new command > was written, we'd add comments to the source code that could be > auto-generated into test cases. Sadly, I think the plan was too > ambitious. Well that was one idea -- and it need not be as elaborate as comments or anything. I was thinking more along the lines of having a testing framework written in something like perl (as many do exist) which could be used to aggregate many test of different types (Styles, Menus, Decors, etc) all of which have a common interface, for exmple. That way, reports can easily be generated, etc. > I think the Purify tests put too much of a burden on the project and > we shouldn't put a lot of effort into them. Hmm -- as they stand at the moment, most likely they do. But I have already appreciated their benefit first-hand, despite them being somewhat outdated already. If it wasn't for those tests, Dan, I'd not have been able to fix your menu background pixmap issue back in December. :) I certainly don't think anyone's efforts are in vain whatsoever if they wanted to make a start on this -- but yes, it might initially be boring, but the benefits for FVWM which come from it are likely to be huge in terms of bug-fixing, spotting problems, etc. -- Thomas Adam
