Thomas Adam <[email protected]> writes: > On Sat, Jun 12, 2010 at 11:16:02PM +0100, Michael Treibton wrote: > So as for timescales: Personally, I am still working on my xdg-menu > replacement, but it's slow since it's bloody boring, and the script I am > basing it off pretty much sucks. So I am going through the XDG > specification myself since that's easiest. The big problem though, is like > FvwmTabs, this script *unavoidably* relies on external perl modules not > under FVWM's control. In this case: XML::Simple which in turn has to > depend on XML::Parser -- something I am not keen on for two reasons: > > 1. Downstream maintainers have to consider the impact of their > dependencies. > > 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. > So that's where we are. I am almost done with the XDG-menu work, I now need > to make it an almost like-for-like copy to fvwm-menu-desktop, and deprecate > some options that don't make sense from fvwm-menu-desktop anymore as well as > write a manpage for it. Then it needs to go through a crap-load of testing > on a number of different environments (I am hoping Dan Espen can help with > this -- he likes these XDG menus a lot more than I do. :)). I find myself using the XDG menus a bit more lately but for stuff I use all the time I still can't stand a bunch of non-hotkeyed menus. It's really for stuff I use rarely and can't remember the command line for. > 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. 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. 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.
