On Jul 16, Joey Hess wrote: > So there's an entire programming language in there, and this is > probably menu's worst problem. The language is ill-specified, has ad-hoc > syntax, is not very powerful, and the implementation is dog slow. Since > I do mostly agree that having a full programming language on tap for the > menu-methods files, given the great diversity of outputs they need to > support. What I have been feeling would be the best thing to do is to > pick a real programming language (perl or python), and make the files be > written in that. That was my general feeling, as well. What I have so far (the legacy menu file parser) is in Python, and seems reasonably fast. > I note the mention of XSLT elsewhere in this thread. Not being > interested in debating the merits of XML (I feel it's way overkill here, > but almost any data format is better than the existing weird menu file > format), I do hope that you find a more powerful language for the > menu-methods files than XSLT. The existing language they're written in, > for instance. Or intercal or something. :-P My general feeling is that XML is not the way to go, particularly (as others point out) there is a reasonable, widely-supported, UTF-8, i18nized format for menu entries already that does 90% of what we want today (with the next 5% coming soon due to the ill-named "VFolders" specification, and the remaining 5% - mainly needs=wm|vc - we can do with vendor extensions if absolutely needed if the XDG people aren't receptive - which I hope won't be the case [i.e. I hope they will be receptive, to avoid the confusing double-negative]). I'm also not entirely sure how to deal with dwww overloading the menu system for its own nefarious purposes if we do transition to something else, although I believe we can work this into the .desktop format too with the Link type. Chris -- Chris Lawrence <chris@lordsutch.com> - http://www.lordsutch.com/chris/
Attachment:
pgpXpfxWsN14o.pgp
Description: PGP signature