Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

When Gnome-menus for 2.10 is emerged, it puts gnome menus in the appropriate
place, /etc/xdg/menus/,  KDE is set to use both /usr/kde/3.4/etc/xdg/menus and
/etc/xdg/menus, is there any way to set KDE to use /usr/kde/3.4/etc/xdg/menus
and for gnome to use /etc/xdg/menus?

Reproducible: Always
Steps to Reproduce:
1.emerge KDE
2.emerge Gnome

Actual Results:  
Menus in KDE by default will point to /etc/xdg/menus

Expected Results:  
KDE should have continued using /usr/kde/3.4/etc/xdg/menus while gnome uses
/etc/xdg/menus

Not at my computer at the moment, will edit this from home later.

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.