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.
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.
Cheers,
Dominique
>
> Ciao,
> Thomas
--
"We have the heroes we deserve."
