Thomas Funk <t.f...@web.de> writes: > Dan Espen <des...@verizon.net> writes: > > It' works over file weighting because it's too complicated to check > distribution relevant paths for finding the default desktop. > > Can you explain the weighting in terms a user would understand. > I read the code once and still didn't have a clue.
Your code is pretty ingenious, and it solves the single biggest issue I had with the xdg spec. Ie. if finds all the menus a WM might want to make visible to the user. If we go this route, it would be nice if you included some of the comments you made. At least for me, not all of this was obvious. > I was thinking of leaving the choice of menus to generate up to > the user. Of course the distros could do the logical thing > and create a single menu hierarchy or at least set some rules. > > Yes, I thought the same. Not known how to do it with FvwmForm or > FvwmScript but I could implement > an option in fvwm-menu-desktop to printout a string with menus found on > the system like > --show-menus=[all, de-selected] and then the user can select/deselect > via checkboxes which menus > she/he wants to display. For that I have to rewrite the --desktop and > --menu-type functionality to handle > lists then. You'd want something like fvwm-menu-directory front ending FvwmForm. I got a little feedback from the xdg folks: DE> I just don't get the logic of having a standard for DE> just the "applications" category. I believe the rationale is that only applications.menu is reserved by the spec, and XDG_MENU_PREFIX was a way to handle conflicts between different applications.menu shipped by different desktops. No other menu name is defined in the spec, and so we were instead relying on the fact that desktops would not create conflicts. That being said, I don't think I'd be opposed to using XDG_MENU_PREFIX for all .menu files. We should just make sure that it doesn't create any compatibility issue. It doesn't sound to me like they are going to address the issue in the near term. I'd like to implement what's best for Fvwm. If XDG gets it's act together later we can replace what we've done with something simpler. So maybe you can clean up this version a bit more and submit as a patch? Thanks for your efforts, and I'm getting a few python lessons along the way... -- Dan Espen
