On Sat, 9 Oct 2010, Carlos R. Mafra wrote: > > here's an idea, carlos. what if the wmgenmenu stuff wasn't added as a > > new parser per se, but we converted its contents to this wmconfig > > format, shipped that with wmaker, and used that to generate a menu > > wmgenmenu does now? > > Well, why don't we leave wmgenmenu untouched for now? I am still
i don't want to touch it just yet ;) > not familiar with your new menu generator (do we have a sample > configuration to test with? I have no idea what I should use > as input to wmmenugen). the wmconfig sources (arrishq.net) have a number of files in samles/wmconfig/, you can use the wmconfig parser on these. i seem to remember that it was at least at some point in time the redhat way of generating wm menus, you might also find some there, if you have access to rh boxes. the xdg parser can be fed with stuff you probably have already, search for .desktop files on your installation (on deb/ubuntu, they tend to end up in /usr/share/applications, teh intarwebz suggests they do that on opensuse (which i seem to remember you to be using) too. > If I understand correctly, the new wmmenugen creates a menu > based on some file with menu entries, while wmgenmenu tries > to find which applications are in your PATH and creates > a menu based on that. So those are two different approaches > for the menu, right? We can have both, I guess. i plan to add that detection to wmmwnugen soon (what's the point of having menu entries you have no executables for?). not unlikely that (at least for now) only the wmconfig parser (as you probably won't end up with ghost .desktop files), but that's still flexible. > Or perhaps I simply did not understand what you mean by "we > converted its contents to this wmconfig format"... you probably did. the point is we don't compile the list of applications to look for into the menu generator binary, but ship it in separate file. -- [-] mkdir /nonexistent -- To unsubscribe, send mail to [email protected].
