Le Tue, 18 Jun 2013 16:06:50 +0200, Dominique Michel <dominique.mic...@vtxnet.ch> a écrit :
> Le Tue, 18 Jun 2013 14:41:31 +0200, > Thomas Funk <t.funk...@googlemail.com> a écrit : > > > 2013/6/18 Dominique Michel <dominique.mic...@vtxnet.ch> > > > > > Le Mon, 17 Jun 2013 21:24:28 +0200, > > > Thomas Funk <t.f...@web.de> a écrit : > > > > > > > Dominique Michel wrote: > > > > > Portage doesn't give rej file. I used > > > > > patch -p0 < fvwm-menu-desktop-config.fpl.gettext.patch > > > > > to get it. > > > > Perhaps Portage isn't up-to-date with CVS? > > > > > > No, its my own live ebuild which download or update the last CVS > > > code, and do the compilation and installation from this code. It > > > is several month ago I made it and never get in trouble with it. > > > > > Ah, that's the point: ' ... several months ago ...'. The fpl file I > > used to diff was > > several months old. Therefore no rejection. > > Gentoo is a source based distribution. That imply portage doesn't > need tarballs and can also install directly from a code repository. > > I made the ebuild it was several months ago, but the ebuild download > the code from the CVS at its first call, and update it with the last > code from the CVS with each subsequent call. This is the point of a > live ebuild: > - to install a program from its source code repository with the > last version of the code. > > It is scripts in portage for that, called eclass. They can be used > used by the ebuilds for cvs, git, svn, ..., any kind of repository. > > In an overlay like the pro-audio one (the equivalent of multiple > repositories with the binary based distributions - in gentoo this is > just an ebuild (scripts) collection), it is a lot of such live > ebuilds, and the only issue we get with them is, sometime we must > update them when upstream change their build system or the > dependencies. > > I am sure I have the last code. Last time I ran it for fwvm, I see > that portage downloaded the last files committed to the CVS. They was > your last patches from this thread. > > > > > > > BTW, I took a lock at the files in /etc/xdg/menus. They > > > > doesn't > > > > > support the freedesktop additional categories. The > > > > > freedesktop guys are amazing, they write a norm and don't > > > > > respect it. Or I missed something, but the result is the > > > > > generated menus in Fvwm-NightShade only use the main > > > > > categories, which is a mess when you have a lot of apps in > > > > > one category. > > > > Hmmm, sounds strange to me. I will test it on my Xubuntu VM > > > > whether this happens there also. On my Mint I have sub > > > > categories in the menus, so ... > > > > > > I think some distributions can provide their own files > > > in /etc/xdg/menus, when gentoo policy is generally to not > > > interfere with what upstream provide. A notable exception to that > > > is gentoo eudev fork of udev, which is mature now, but that's > > > another subject... > > > > > The easiest way is to log in into KDE/Gnome/Xfce session and have a > > look in their menus. They build them from /etc/xdg/menus/, too. > > I get the same menus than in NightShade. That confirm this is an > upstream issue and that some distributions improve these menus, and > others not. > > And it is more, a lot of applications are missing. I guess this is why > kde provide an utility to find and add them into its menu. > > As example, I didn't get alsaplayer in any of these menus, when > alsaplayer do provide, and install, a compliant alsaplayer.desktop > file. I just see it is not installed. I must search why. > In consequence, the whole xdg menu thing is completely broken > from the root, it have always been, and this have nothing to do with > fvwm-menu-desktop. Well, the additional categories are broken. And this is mess. > > Cheers, > Dominique > > > > > Ciao, > > Thomas > > -- "We have the heroes we deserve."
