Summary: | Once Gnome 2.10 is installed, KDE 3.4 uses its menu in /etc/xdg/menus/ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Cory Grunden <cory.grunden> |
Component: | [OLD] GNOME | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | basic, ct85711, desktop-wm+disabled, dopey, douglas.pollock, gnome, gtgentoo, lanius, sbriesen |
Priority: | High | ||
Version: | 2005.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 95867 |
Description
Cory Grunden
2005-04-20 14:51:30 UTC
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.200 50125-r1, 2.6.12-rc2-nitro1 i686) ================================================================= System uname: 2.6.12-rc2-nitro1 i686 Intel(R) Pentium(R) 4 CPU 1.50GHz Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 10 2005, 15:40:08)] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://gentoo.mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source ftp://gentoo.agsn.ca" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X acpi aim alsa apm arts avi berkdb bitmap-fonts bmp cdr crypt cups curl divx4linux emboss encode esd fam flac foomaticdb fortran ftp gaim gdbm gif gnome gpm gstreamer gtk gtk2 hal imagemagick imlib java jpeg junit kde kdeenablefinal ldap libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg ncurses nls nptl nvidia ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl spell sse sse2 ssl svga tcpd tiff truetype truetype-fonts type1-fonts udev usb videos vorbis win32codecs xine xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS I too get this problem. After emerging gnome packages I lost half my kde menus. This is not a minor bug imho and should be upped to at least medium Portage 2.0.51.20-r5 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6alex1 i686) ================================================================= System uname: 2.6.11-gentoo-r6alex1 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.11 ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.3 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="no" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS=" http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://ftp.easynet.nl/mirror/gentoo/ http://mirror.switch.ch/mirror/gentoo/ http://ftp.heanet.ie/pub/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LINGUAS="en_GB" MAKEOPTS="-j7" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.uk.gentoo.org/gentoo-portage" USE="x86 X Xaw3d aac aalib acpi alsa apache2 apm arts audiofile authdaemond avi bash-completion bcmath berkdb bitmap-fonts bzip2 bzlib calendar cdb cddb cdparanoia cdr cpdflib crypt cscope ctype cups curl curlwrappers dba dbx dga dio directfb divx4linux doc dts dv dvb dvd dvdread ecc edl elf emboss encode esd examples exif fam fbcon ffmpeg flac flash flatfile font-server foomaticdb fortran fpx ftp gd gdbm ggi gif gimpprint gmp gnome gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml guile i8x0 iconv idea ieee1394 imagemagick imap imlib inifile ithreads jack jack-tmpfs java javamail javascript jbig jikes jpeg jpeg2k junit jython kde kdeenablefinal kdexdeltas latex lcms libcaca libg++ libwww live lm_sensors logitech-mouse lzo mad maildir math matroska mcal memlimit mhash mikmod mime ming mmap mmx mmxext mng mono motif mozilla mp3 mpeg mpi mysql mythtv nas ncurses network nls nntp no-htdocs nptl nptlonly objc odbc offensive ogg oggvorbis openexr opengl oss pam pcntl pcre pdflib perl pg-hier php plotutils png portaudio posix postgres povray ppds python qt quicktime readline real rhino rpm rtc ruby samba scanner sdk sdl session sharedext sharedmem simplexml slang sndfile snmp soap sockets speex spell spl sqlite sse sse2 ssl svg svga sysfs sysvipc tcltk tcpd tetex tga theora threads tidy tiff tokenizer truetype truetype-fonts type1-fonts ucs2 unicode urandom usb userlocales v4l v4l2 vcd videos vidix vorbis wddx win32codecs wmf xanim xine xinerama xml xml2 xmlrpc xmms xpm xprint xscreensaver xsl xv xvid xvmc zlib video_cards_i810 video_cards_i830 linguas_en_GB userland_GNU kernel_linux libc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS The same. I agree it isn't minor bug. Yeah, it is minor, all I have to do is when it is time for me to use gnome (my wife uses KDE), I just have to do a mv /etc/xdg/menus/gapplications.menu /etc/xdg/menus/applications.menu, to give myself a menu again, and then do it back again. I'm sure I could write a little bash script to do this, but I shouldn't have to, I actually expected this little bug to be addressed by now. None of the other distros have this issue from what I've heard. I guess the problem is the non-default virtual slotting that KDE does (/usr/kde/<version> stuff). The kde menus system sanely check for the correct menus syswide location, now finds the gnome stuff there which doesn't check all the non-default versioned locations of kde .desktops. Solutions if this is really the case ... 1) kde to follow FHS 2) fix the menus to check for all kde versions, but this costs some upkeep (there goes my mana). The latter may lead to duplication of entries, not sure how xdg would handle it. Couldn't you create a single /etc/xdg/menus/applications.menu with both the default gnome menus and the default kde menus, and then use the 'show only in gnome' and 'show only in kde' options? i don't know much, just a newbie question. foser: (almost) only kde-base/* stuff goes into $KDEDIR, other kde apps go into /usr. Your point 2 is invalid.
>1) kde to follow FHS
that should have nothing to do with it and i told you it won't happen before kde 4. Shall i continue with broken gnome stuff, which should be fixed asap? It worked fine before, otherwise we'd get this bug earlier. So Gnome 2.10 is producing the problem. The question is - what changed?
According to `kde-config --path xdgconf-menu` KDE 3.4 uses
/home/carsten/.config/menus/:/usr/kde/3.4/etc/xdg/menus/ on my box.
*** Bug 91226 has been marked as a duplicate of this bug. *** After a long story that what I say isn't true (might be, I don't have KDE around so as stated it was just a guess) this is what you post : /usr/kde/3.4/etc/xdg/menus/ ... my point exactly Gnome is 'producing' the problem by actually creating a syswide menu in the right place, but that much was analyzed in the initial comment. In FHS we would have a file-collision, which is probably what we should keep in mind when resolving this. KDE has to set XDG_CONFIG_DIRS and XDG_DATA_DIRS in its env file: cat /etc/env.d/46kdepaths-3.4 PATH=/usr/kde/3.4/bin ROOTPATH=/usr/kde/3.4/sbin:/usr/kde/3.4/bin LDPATH=/usr/kde/3.4/lib CONFIG_PROTECT="/usr/kde/3.4/share/config /usr/kde/3.4/env /usr/kde/3.4/shutdown" XDG_DATA_DIRS=/usr/kde/3.4/share:/usr/share XDG_CONFIG_DIRS=/usr/kde/3.4/etc/xdg after that run kbuildsycoca and your menus are fine again so i recommened to add XDG_DATA_DIRS=/usr/share to kde-base/kde-env and XDG_DATA_DIRS=${PREFIX}/share XDG_CONFIG_DIRS=${PREFIX}/etc/xdg to kde-base/kdelibs great! I test it. But this should be fixed in arts-3.4.0 (huh?) then. forget what I've written ;) Reply to: ------- Additional Comment #10 From Heinrich Wendel 2005-05-02 16:49 PST ------- KDE has to set XDG_CONFIG_DIRS and XDG_DATA_DIRS in its env file: cat /etc/env.d/46kdepaths-3.4 PATH=/usr/kde/3.4/bin ROOTPATH=/usr/kde/3.4/sbin:/usr/kde/3.4/bin LDPATH=/usr/kde/3.4/lib CONFIG_PROTECT="/usr/kde/3.4/share/config /usr/kde/3.4/env /usr/kde/3.4/shutdown" XDG_DATA_DIRS=/usr/kde/3.4/share:/usr/share XDG_CONFIG_DIRS=/usr/kde/3.4/etc/xdg after that run kbuildsycoca and your menus are fine again Fine in KDE, not fine in Gnome, that sets a global statement. ok, then KDE has to set it during startkde possible place: /usr/kde/3.4/env/ ?? ----8<--------8<--------8<--------8<--------8<--------8<---- [/usr/kde/3.4/env/xdg.sh] export XDG_DATA_DIRS="/usr/kde/3.4/share:/usr/share" export XDG_CONFIG_DIRS="/usr/kde/3.4/etc/xdg" ----8<--------8<--------8<--------8<--------8<--------8<---- works for me! The KDE startup-script sources /usr/kde/3.4/env/*.sh ----8<--------8<--------8<--------8<--------8<--------8<---- exepath=`kde-config --path exe` for prefix in `echo "$exepath" | sed -e 's^/bin/^/env/^g;s^:^ ^g'`; do for file in "$prefix"*.sh; do test -r "$file" && . "$file" done done ----8<--------8<--------8<--------8<--------8<--------8<---- So right place to add it is: kdebase-startkde-3.4.0 i consider that a blocker bug for marking kde 3.4 stable, kde team? Fixed in kdebase-3.4.0-r1/kdebase-startkde-3.4.0-r1, adding a file in /usr/kde/3.4/env/. ths fixes the kde*-meta installations. What about non-meta installations? > ths fixes the kde*-meta installations. What about non-meta installations?
kdebase-3.4.0-r1 was patched, too.
ahh, ok. ;) Same problem seems to apply to KDE 3.3.2 - gnome menus screw KDE menus I just committed kdebase-3.3.2-r3 which should fix the issue, please give it a try. but where can i download kdebase-3.3.2-r3? it isnt i portage yet! This does NOT appear to be "fixed". We should't have to upgrade to packages that aren't marked as stable to correct a problem. Either the newer (fixed) version should be marked stable, or if not ready yet, a different release needs to have that patch backported to it and marked stable. Thoughts? (In reply to comment #26) > This does NOT appear to be "fixed". We should't have to upgrade to packages > that aren't marked as stable to correct a problem. My thoughts exactly. Concerning me, this bug is far from fixed as long as people are able to "emerge into" this bug as I did when I installed stable packages from Portage. Does the fix work for kde 3.4.1? Not to mention the "fix" breaks the icons in evolution. http://bugs.gentoo.org/show_bug.cgi?id=95867 (In reply to comment #26) > This does NOT appear to be "fixed". We should't have to upgrade to packages > that aren't marked as stable to correct a problem. > > Either the newer (fixed) version should be marked stable, or if not ready yet, a > different release needs to have that patch backported to it and marked stable. > > Thoughts? Are you suggesting that we should commit an ebuild directly in the stable branch? That's not going to happen. Actually, if anyone has a fix for this problem that does not cause bug 95867 please let us know fast, kdebase-3.3.2-r3 has to be marked stable now and bug 95687 is less grave. (In reply to comment #30) > > Either the newer (fixed) version should be marked stable, or if not ready > yet, a > > different release needs to have that patch backported to it and marked > stable. > > > > Thoughts? > > Are you suggesting that we should commit an ebuild directly in the stable > branch? That's not going to happen. No, I am suggesting that **if necessary** you branch off of the existing/current stable release (of kdebase-3.3.2-r1) and apply a single change that only contains the needed fix and nothing else. This makes it easy to test only that one change and move it to stable quickly as a new release -- MUCH FASTER than your "testing" version (kdebase-3.3.2-r3) might be able to promote. This is standard release management stuff -- I'm not suggesting anything radical at all here. Sorry if I didn't explain this well enough. > No, I am suggesting that **if necessary** you branch off of the existing/current > stable release (of kdebase-3.3.2-r1) and apply a single change that only > contains the needed fix and nothing else. This makes it easy to test only that > one change and move it to stable quickly as a new release -- MUCH FASTER than > your "testing" version (kdebase-3.3.2-r3) might be able to promote. > > This is standard release management stuff -- I'm not suggesting anything radical > at all here. Our system works with only two keywords (x86 and ~x86), so that's the best we can do, sorry. Anyway, kdebase-3.3.2-r3 is now stable on x86. This bug is also in KDE 3.4.1, can you apply your fix there as well? (In reply to comment #33) > This bug is also in KDE 3.4.1, can you apply your fix there as well? It was already fixed in comment #19. Alright thanks, there happened to be a custom gnome menu in ~/.config, when I deleted that all worked well, thanks. I'm very sorry to inform you that the kdebase-3.3.2-r3 emerge does NOT solve this problem. Still sticks to my install as a fly. :) I've tried some things as described in a couple of forum posts, but this now just made me end up with no menu in gnome and KDE. Doing a remerge of kdebase and going to remerge gnome-menus (I guess?) What is exactly up with this (this buglist is a bit vague in parts). Miracously it solved now :D I still don't think this bug is entirely resolved. When SMEG or any other Gnome menu editor is used, it writes gnome menus to ~/.config/, which KDE 3.4.x will use. This issue needs to be resolved because of the situation where user A needs to add a menu entry into Gnome, and then user A's wife logs on to the same username in KDE, her menus are now "weird". The objective of the XDG menus is to have a single menu for all desktops. We should try to make that work. (Disclaimer, I never use the menu :-) If we set the XDG paths to include the KDE path(s) as well as the gnome/standard ones, what will break? For me everything seems to work (with kde+gnome merged, shared menus) except that gnome doesn't display KDE icons from /usr/kde/.... I suppose there's a systemwide way to tell gnome to look there for supplemental icons (unless we're going to hit a theme problem, with gnome using the 'gnome' theme by default...) And bug #95867 can apparently by avoided by setting XDG_DATA_DIRS=/usr/share:/usr/kde/3.4/share and not the other way around. Or do people really want to keep their kde and gnome menus separate? In that case we should do the above (for other WMs' benefit), then make kde & gnome use category filtering. (I don't know if that's supported yet.) Re: comment #38: what's weird? I just tried a trivial edit using smeg and it seems to apply correctly to both gnome and kde (3.4.1) menus. If you're referring to the fact that the edit applies to KDE at all, then the husband & wife should have separate user accounts. As a temporary fix, I found that if I create a link between /usr/kde/etc/xdg/menus and /etc/xdg/menus/kde, that the gnome menu is unaffected, but the kde menu is restored except for a few annoying duplicates. However, some of the applications that had totally disappeared before are now acessable again, so this is at least an improvement. I don't know what this would do if you run other window managers, however. It would mean other WMs won't include KDE items in their menus. I'd like to hear what everyone wants to see as per comment 39. (In reply to comment #42) > It would mean other WMs won't include KDE items in their menus. I'd like to > hear what everyone wants to see as per comment 39. This thread seems a good start: http://lists.freedesktop.org/archives/xdg/2005-June/006973.html OK. That thread makes the argument that esp. on multiuser systems desktop menus should be kept separate, with .menu files prefixed with kde- etc. The main (nonprefixed) files in /etc/xdg/menus would be used by all desktops and thus include only common stuff. Sounds good to me, except that we don't have a good criterion for what goes in the common stuff and what doesn't, unless nothing at all does. Given the kde-base, kde-non-base and gnome install prefixes, we can't use the 'installed in /usr' criterion. KDE already installs a kde-applications.menu etc. in addition to applications.menu, and gnome doesn't. So this would require gnome to install that instead of applications.menu, and some common ebuild to install an agreed-on applications.menu. OTOH, if we don't have a common applications.menu at all and force each desktop to use its own menu, we may have to change some desktops/apps' source code to not refer to applications.menu and it would also be nonstandard according to the fd.o spec (I need to reread that, I'm not sure anymore...) Too late in the night for me to make a good proposal beyond this summing up, I'll come back to it next week. When I wrote 'criterion' above I didn't mean 'how are we going to choose apps to go into the common menu' - that should be the apps that aren't 'affiliated' with a DE - but rather 'how are we going to make applications.menu include eg lyx and ooffice, but not gedit and nautilus'. There's also the question of whether non-kde-base apps installed in /usr should be included in the common menu... Is it possible to create a menu under /etc/xdg/menus, with both the gnome menu and the kde menu, and then use the ShowOnlyIn options for the desktop files? So that in gnome, you see the gnome menu,and in kde, you see the kde menu. and then also have a little gtk or qt program that will allow you to add in (change ShowOnlyIn options) for desktop files? As I now understand this, the filtering should rather be based on categories. Each .desktop file has a Categories= line, all KDE apps include 'KDE' and gnome-affiliated ones include 'GNOME'. KDE and Gnome should then use separate applications.menu files which would tell them to filter the categories appropriately. The only issue with that is that gnome installs its applications.menu in a central location, so a third WM that isn't specially configured will by default see gnome menu entries and not kde ones :-( Could gnome install & use an applications.menu somewhere else which would filter by category=GNOME, and leave /etc/xdg/menus/applications.menu unfiltered? Does that make sense? I'm relatively new to xdg menu layout as I never really paid attention to it until the last couple of days when I started messing with CrossOver 5.0 which uses XDG menu files, and I did some research and thought I'd toss in my 2c. It seems to me that the intent of xdg was a unified menu layout. In that case, it seems rather weird that /etc/xdg/menus exists for gnome, and kde uses /usr/kde/[version]/etc/xdg/menus. That's not really unified menu layout if the two separate desktops use their own layout. The drawback of having separate layouts is that crossover is only expecting 1, so it will put it in either /etc/xdg or XDG_CONFIG_DIRS set directory. I currently have to manually maintain the menus across the two locations for myself (KDE user) and my wife (Gnome user). It's somewhat confusing. If I'm missing something here, feel free to point out my stupidity. *** Bug 111763 has been marked as a duplicate of this bug. *** well, I know don't know the specs right now for this xdg menu system; but; wouldn't it be better if we make all the menus initialy visible to all wm's; then allow the user to make a custom .menu (kept in their home directorys respectfuly) file with will over-ride the system one to not display certain ones. Pretty similar to how the use flags works; on having a global default set; then allow you to add/remove them. right now I am in the process of updating my kdebase to 3.4.3; currently marked unstable/untested for amd64. make that kdebase-3.4.2; as kde-meta-3.4.3 is broken from missin dependency; bug already posted. If my suggestions (comments #44 #45 #47) makes sense, could a gnome dev respond? If not, can someone make a different proposal for how things should be and what needs to be done? CCing desktop-wm: any WM using XDG menus will be affected by anything decided here, and an open question is - should a WM that isn't a full DE show KDE or Gnome menu items only (by default & asking the user of course), or both, or none? I think that not just menu items are affected but all .desktop files. For instance, the stuff in share/services/. That's IMO even more important. This is fixed for me with Gnome 2.14. What changed between gnome 2.10 and 2.14? personaly I can't really say that Gnome 2.14 fixed it for me; as I still have the problem of where I end up manualy sym linking the files to another directory so I can use the program easier. As I used both kde and gnome programs together. Like I perfer to use Gnome; but I perfer to use like koffice, quanta and kdevelop alot more. So I usualy have the librarys for kde installed along with everything for Gnome. Anymore I am actualy getting tired of having to redoing every sym link all over; for each new version of the kde programs that comes out (they like to slot everything; which I hate the most personaly). In the end I decided to switch to kde; and make do; at least this way I can see all of my programs that I install and don't have any of the problems of gnome programs not showing up in kde and vice versa. (In reply to comment #56) > (they like to slot everything; which I hate the most > personaly). That is exactly the problem. But I think with a few modifications to menu files you could come a long way to including the kde .desktop items. Check the specs http://standards.freedesktop.org/menu-spec/ well the biggest thing that I have seren; which is the largest problem on changing the kde menu system; is that not all of the .menu and .desktop files are stored in the same place. This is one issue I am running into often. Like it is said quanta, kdevelop, koffice and kde is all integrated together. Only thing is; kdevelop and wuanta and koffice may not put their .desktop files in the same place. They are in various locations which kde searches. So any changes is going have to come from kde itself. As from what I am seeing; half the dev's here or more (I don't blame them one bit, as I wouldn't either) don't want to go and fix 50+ packages just to solve the problem. At least if it is fixed from kde it's self; then they could fix the problem on their side; and include the fix on the next update. Thus when all the other packages that is integrated into kde is also upgraded; the fix will filter through all/most of them. (In reply to comment #57) > (In reply to comment #56) > > (they like to slot everything; which I hate the most > > personaly). > > That is exactly the problem. But I think with a few modifications to menu files > you could come a long way to including the kde .desktop items. Don't care for the slotted versions. They're not meant to be used at the same time. You get all paths to search for via `kde-config --path apps`. I know that is what it's suppose to be; then why is kde having to manualy set the paths so it can load the .menu and the .desktop files? It's also why gnome can't load find the automaticly either. That file is broken; as to fully work and echo out the paths without anything running for it to work. Kindly review http://bugs.gentoo.org/page.cgi?id=fields.html#bug_severity Is this still an issue with kde-3.5.5? According to /usr/kde/3.5/env/xdg.sh: export XDG_DATA_DIRS="/usr/kde/3.5/share:/usr/share" export XDG_CONFIG_DIRS="/usr/kde/3.5/etc/xdg" KDE only uses /usr/kde/3.5/etc/xdg to determine menu layout. Menu items are apparently read first from /usr/kde/3.5/share then /usr/share As far as I can tell, this should solve the problem originally reported in this bug. I still think it's odd that kde and gnome use separate xdg config directories considering that the point of XDG was to provide a single unified configuration for all desktop environments. But that's probably beyond the scope of this bug. Yeah, I think this bug is resolved. |