From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=unavailable autolearn_force=no version=4.0.0 Received: from mail.fidnet.com (one.fidnet.com [216.229.64.71]) by chiba.3jane.net (Postfix) with SMTP id 52D02AC969 for ; Wed, 17 Apr 2002 23:23:37 -0500 (CDT) Received: (qmail 12776 invoked from network); 18 Apr 2002 04:23:36 -0000 Received: from dialup-mo-16.stjames.fidnet.com (216.229.82.16) by one.fidnet.com with SMTP; 18 Apr 2002 04:23:35 -0000 Subject: Re: [gentoo-dev] Menu System From: Tod M Neidt To: gentoo-dev@gentoo.org In-Reply-To: <20020417230748.43bb3722.jnelson@jamponi.net> References: <200204171007.54557.marioy@logos.upb.edu.co> <200204172023.06703.danarmak@gentoo.org> <20020417130833.6250e75b.jnelson@jamponi.net> <200204171729.46831.marioy@logos.upb.edu.co> <1019101288.3695.1250.camel@Q.neidt.net> <20020417230748.43bb3722.jnelson@jamponi.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 17 Apr 2002 23:22:45 -0500 Message-Id: <1019103767.3696.1264.camel@Q.neidt.net> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 29fb424f-7b6e-41a6-86fc-2d92712b8ca1 X-Archives-Hash: 025f2ea6a62323c450f494329b472250 On Wed, 2002-04-17 at 23:07, Jon Nelson wrote: Hi! My post got mangled and was incomplete. I'm appending it whole :) > > The problem with that approach is that if you later decide to use gnome, > you would have to re-emerge everything to get its menu entry. Only if gnome wasn't in the USE. But that is a good point, if gnome is added to the USE later. But then a separate stand alone script could be made to parse /var/db/pkg/ and just merge any menu items not present that would be with the new USE variable (ok maybe I'm stretching abit :) > Having each program place its menu entry (or entries) in a central > location (ala Debian, again), and then having a post-process program > zip through and create the KDE, GNOME, AfterStep, BlackBox, and > so on "system" menus sounds better to me. Except from my experience debians menu system becomes a complete mess. Having to drill down through multiple submenus to get to what you want. I, personally don't care for that. The advantage to this implementation, is that the menu item is inserted into the existing submenus categories. Regards, tod Full previous post (for what its worth): Hi! My thought on this issue would be the addition of a 'domenu' helper script that could be a one line addition in the src_install function. For example, src_install() { make blah blah install || die dodoc blah blah domenu } The 'domenu' script would cascade through the desktop USE variables (i.e. gnome, kde, etc , might have to add some for other desktops that don't already have a USE variable.) If the USE variable for a particlular desktop is set then insert a menu item. for example (off the top of my head, so illustrative, not necessarily working), if use gnome; then if [ -e ${FILESDIR}/${PN}.desktop]; then submenu=$( grep Type ${FILESDIR}/${PN}.desktop | \ sed "s:\(Type=\)\([[:alpha:]]*\).*:\2:" ) insinto /usr/share/gnome/apps/${submenu} doins ${FILESDIR}/${PN}.desktop fi if [ -e ${FILESDIR}/${PN}-logo.*]; then insinto /usr/share/pixmaps doins ${FILESDIR}/${PN}-logo.* fi fi Presumably, someone familar with the other desktop environments menus could work up a similar section for those.