Re: CVS dane: Patches from Thomas Funk
Dominique Michel dominique.mic...@vtxnet.ch writes: Le Mon, 17 Jun 2013 20:23:29 -0500, c...@math.uh.edu a écrit : CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: dane13/06/17 20:23:29 Modified files: bin: Tag: branch-2_6 ChangeLog fvwm-menu-desktop-config.fpl fvwm-menu-desktop.in po : Tag: branch-2_6 ChangeLog fvwm.de.po fvwm.pot The compilation didn't update the gmo file with the last translation. From into the po directory: # make po-update make: *** No rule to make target `po-update'. Stop. tuxstudio po # make make: Nothing to be done for `all' To get them, I have to cd into the po dir, and issue # make fvwm.de.gmo rm -f fvwm.de.gmo /usr/bin/gmsgfmt -c --statistics -o fvwm.de.gmo fvwm.de.po 106 translated messages. Maybe I missed something into the configure step, but I didn't see any obvious option for that. You're right. I remembered to do that and promptly forgot about it. There are instructions in the po directory on how to build the gmo file. I'll get to it. -- Dan Espen
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
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.
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
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.
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
2013/6/18 Dominique Michel dominique.mic...@vtxnet.ch 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. Ah, ok I understand. I haven't used Gentoo anytime. 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. Yes, if it so, then it is a big mess :( Btw. you have listed in a last mail your menu files: $ ls -R /etc/xdg/menus /etc/xdg/menus: applications-merged kde-information.menu xfce-applications.menu gnome-applications.menu lxde-applications.menuxfce-settings-manager.menu kde-4-applications.menu lxlauncher-applications.menu Did you have activated all checkboxes in fvwm-menu-desktop-config.fpl? Sometimes you find sub menus in menus where you haven't think about. Cheers, Thomas
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Tue, 18 Jun 2013 16:46:21 +0200, Thomas Funk t.funk...@googlemail.com a écrit : 2013/6/18 Dominique Michel dominique.mic...@vtxnet.ch 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. Ah, ok I understand. I haven't used Gentoo anytime. I think this portage feature is one of the reasons why many gentoo users are developers. The first time install is very time consuming, but after, you get a continuous update process, and will never need to reinstall the whole distribution, that even with a many years old installation. 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. Yes, if it so, then it is a big mess :( It is the main reason why I begun to use Fvwm-Crystal it was a few years ago. To made its menu system to be FreeDesktop compliant, inclusive the additional categories, was one of the first things I made. It doesn't care about the files into /etc/xdg/menus, but use directly the desktop files, that to add only the missing menu entries and icons into Fvwm-Crystal applications database. Which can be tailored independently by the user. Btw. you have listed in a last mail your menu files: $ ls -R /etc/xdg/menus /etc/xdg/menus: applications-merged kde-information.menu xfce-applications.menu gnome-applications.menu lxde-applications.menuxfce-settings-manager.menu kde-4-applications.menu lxlauncher-applications.menu Did you have activated all checkboxes in fvwm-menu-desktop-config.fpl? Sometimes you find sub menus in menus where you haven't think about. Yes, but I don't get the additional categories in any of them. I can send you these files, or to the list, if someone want to look at the differences. Ciao, Dominique Cheers, Thomas -- We have the heroes we deserve.
CVS dane: commit generated fvwm.de.gmo file
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane13/06/18 16:58:56 Modified files: po : Tag: branch-2_6 fvwm.de.gmo Log message: commit generated fvwm.de.gmo file
