Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 89870 - Once Gnome 2.10 is installed, KDE 3.4 uses its menu in /etc/xdg/menus/
Summary: Once Gnome 2.10 is installed, KDE 3.4 uses its menu in /etc/xdg/menus/
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
: 91226 111763 (view as bug list)
Depends on:
Blocks: 95867
  Show dependency tree
 
Reported: 2005-04-20 14:51 UTC by Cory Grunden
Modified: 2006-12-14 17:47 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cory Grunden 2005-04-20 14:51:30 UTC
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.
Comment 1 Cory Grunden 2005-04-20 15:53:25 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
Comment 2 A Blamey 2005-05-01 14:20:47 UTC
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

Comment 3 Andrew Gaydenko 2005-05-01 16:42:55 UTC
The same.

I agree it isn't minor bug.
Comment 4 Cory Grunden 2005-05-02 06:12:49 UTC
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.
Comment 5 foser (RETIRED) gentoo-dev 2005-05-02 13:47:23 UTC
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.
Comment 6 Cory Grunden 2005-05-02 14:17:42 UTC
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.
Comment 7 Carsten Lohrke (RETIRED) gentoo-dev 2005-05-02 15:23:12 UTC
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.

Comment 8 foser (RETIRED) gentoo-dev 2005-05-02 15:38:31 UTC
*** Bug 91226 has been marked as a duplicate of this bug. ***
Comment 9 foser (RETIRED) gentoo-dev 2005-05-02 15:47:20 UTC
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.

Comment 10 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-02 16:49:16 UTC
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
Comment 11 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-02 16:55:42 UTC
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
Comment 12 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-02 16:57:39 UTC
great! I test it. But this should be fixed in arts-3.4.0 (huh?) then.
Comment 13 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-02 16:58:33 UTC
forget what I've written ;)
Comment 14 Cory Grunden 2005-05-03 21:04:03 UTC
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.
Comment 15 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-03 22:37:26 UTC
ok, then KDE has to set it during startkde
Comment 16 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-04 01:28:52 UTC
possible place: /usr/kde/3.4/env/ ??
Comment 17 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-04 01:46:41 UTC
----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
Comment 18 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-08 10:45:57 UTC
i consider that a blocker bug for marking kde 3.4 stable, kde team?
Comment 19 Gregorio Guidi (RETIRED) gentoo-dev 2005-05-11 13:13:38 UTC
Fixed in kdebase-3.4.0-r1/kdebase-startkde-3.4.0-r1, adding a file in /usr/kde/3.4/env/.
Comment 20 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-12 01:52:41 UTC
ths fixes the kde*-meta installations. What about non-meta installations?
Comment 21 Gregorio Guidi (RETIRED) gentoo-dev 2005-05-12 03:21:54 UTC
> ths fixes the kde*-meta installations. What about non-meta installations?

kdebase-3.4.0-r1 was patched, too.
Comment 22 Stefan Briesenick (RETIRED) gentoo-dev 2005-05-12 05:28:25 UTC
ahh, ok. ;)
Comment 23 Mark Clegg 2005-06-07 12:31:14 UTC
Same problem seems to apply to KDE 3.3.2 - gnome menus screw KDE menus 
Comment 24 Gregorio Guidi (RETIRED) gentoo-dev 2005-06-08 09:19:59 UTC
I just committed kdebase-3.3.2-r3 which should fix the issue, please give it a 
try. 
Comment 25 potatoface 2005-06-08 12:32:07 UTC
but where can i download kdebase-3.3.2-r3?
it isnt i portage yet!
Comment 26 Greg Tassone 2005-06-13 15:07:15 UTC
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?
Comment 27 Tobias Weisserth 2005-06-16 14:00:33 UTC
(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.
Comment 28 Cory Grunden 2005-06-17 08:25:04 UTC
Does the fix work for kde 3.4.1?
Comment 29 Conor Richard 2005-06-17 18:30:07 UTC
Not to mention the "fix" breaks the icons in evolution. 

http://bugs.gentoo.org/show_bug.cgi?id=95867
Comment 30 Gregorio Guidi (RETIRED) gentoo-dev 2005-06-18 04:33:02 UTC
(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. 
 
Comment 31 Greg Tassone 2005-06-19 01:59:40 UTC
(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.
Comment 32 Gregorio Guidi (RETIRED) gentoo-dev 2005-06-19 16:35:25 UTC
> 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. 
 
Comment 33 Cory Grunden 2005-06-20 04:20:36 UTC
This bug is also in KDE 3.4.1, can you apply your fix there as well?
Comment 34 Gregorio Guidi (RETIRED) gentoo-dev 2005-06-20 04:50:51 UTC
(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. 
Comment 35 Cory Grunden 2005-06-20 07:37:32 UTC
Alright thanks, there happened to be a custom gnome menu in ~/.config, when I
deleted that all worked well, thanks.
Comment 36 Herald Becker 2005-06-22 03:48:17 UTC
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).
Comment 37 Herald Becker 2005-06-22 03:52:18 UTC
Miracously it solved now :D
Comment 38 Cory Grunden 2005-06-27 09:29:05 UTC
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".
Comment 39 Dan Armak (RETIRED) gentoo-dev 2005-06-28 11:28:03 UTC
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.) 
Comment 40 Dan Armak (RETIRED) gentoo-dev 2005-06-28 11:29:34 UTC
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.  
Comment 41 Christine Bussman 2005-07-01 07:13:03 UTC
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.
Comment 42 Dan Armak (RETIRED) gentoo-dev 2005-07-01 07:47:11 UTC
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. 
Comment 43 Gregorio Guidi (RETIRED) gentoo-dev 2005-07-02 14:54:26 UTC
(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 
 
Comment 44 Dan Armak (RETIRED) gentoo-dev 2005-07-02 15:10:02 UTC
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. 
Comment 45 Dan Armak (RETIRED) gentoo-dev 2005-07-02 15:14:11 UTC
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... 
Comment 46 Cory Grunden 2005-07-05 07:17:38 UTC
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?
Comment 47 Dan Armak (RETIRED) gentoo-dev 2005-07-08 12:14:06 UTC
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? 
Comment 48 Andy Wang 2005-10-28 12:54:24 UTC
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.
Comment 49 Gregorio Guidi (RETIRED) gentoo-dev 2005-11-16 00:48:16 UTC
*** Bug 111763 has been marked as a duplicate of this bug. ***
Comment 50 Chris Torske 2005-11-16 08:01:58 UTC
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.
Comment 51 Chris Torske 2005-11-16 08:55:56 UTC
make that kdebase-3.4.2; as kde-meta-3.4.3 is broken from missin dependency; bug
already posted.
Comment 52 Dan Armak (RETIRED) gentoo-dev 2006-01-14 10:19:17 UTC
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?
Comment 53 Dan Armak (RETIRED) gentoo-dev 2006-03-26 13:05:28 UTC
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.
Comment 54 Cory Grunden 2006-03-27 06:13:15 UTC
This is fixed for me with Gnome 2.14.
Comment 55 Dan Armak (RETIRED) gentoo-dev 2006-03-27 10:10:06 UTC
What changed between gnome 2.10 and 2.14?
Comment 56 Chris Torske 2006-03-27 10:25:25 UTC
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.
Comment 57 foser (RETIRED) gentoo-dev 2006-03-27 13:27:08 UTC
(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/
Comment 58 Chris Torske 2006-03-28 05:14:19 UTC
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.
Comment 59 Carsten Lohrke (RETIRED) gentoo-dev 2006-03-28 05:52:14 UTC
(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`.
Comment 60 Chris Torske 2006-03-28 19:35:16 UTC
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.
Comment 61 Charlie Shepherd (RETIRED) gentoo-dev 2006-12-13 16:51:15 UTC
Kindly review http://bugs.gentoo.org/page.cgi?id=fields.html#bug_severity

Is this still an issue with kde-3.5.5?
Comment 62 Andy Wang 2006-12-14 09:19:38 UTC
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.
Comment 63 Cory Grunden 2006-12-14 17:47:34 UTC
Yeah, I think this bug is resolved.