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 vsmtp.wi.securepipe.com (vsmtp.wi.securepipe.com [64.73.37.228]) by chiba.3jane.net (Postfix) with SMTP id 1E9D1AC42F for ; Thu, 18 Apr 2002 11:01:08 -0500 (CDT) Received: (qmail 1899 invoked from network); 18 Apr 2002 15:47:03 -0000 Received: from unknown (HELO honker.jamponi.net) (216.165.181.157) by 0 with SMTP; 18 Apr 2002 15:47:03 -0000 Date: Thu, 18 Apr 2002 11:01:40 -0500 From: Jon Nelson To: gentoo-dev@gentoo.org Cc: tod@gentoo.org Subject: Re: [gentoo-dev] Menu System Message-Id: <20020418110140.1e399e69.jnelson@jamponi.net> In-Reply-To: <1019103767.3696.1264.camel@Q.neidt.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> <1019103767.3696.1264.camel@Q.neidt.net> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 6abb635f-476b-479e-8a19-1900d41747a5 X-Archives-Hash: d7e4ec85fc82742482d77ba5541cc80e On 17 Apr 2002 23:22:45 -0500 Tod M Neidt wrote: > 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. Can you elaborate on that? I came to Gentoo after many years with (primarily) Debian at home, and RedHat and others at work. I've not experienced any kind of issues with the menuing system with Debian, unlike RedHat (whose menuing system is utterly worthless). > Having to drill down through multiple submenus to get to what you want. > I, personally don't care for that. That is a detail that doesn't have anything to do with the mechanism, but the policy surround the the contents of the entries should be. > The advantage to this implementation, is that the menu item is inserted > into the existing submenus categories. Where the menu is inserted has nothing to do with how or when the entries are stored or processed. Only how. Additionally, your proposed mechanism has the significant disadvantage of having to know how to process ebuild files, versus just knowing how to handle menu entries. Have you ever looked at how Debian handled their menuing system? It's a far superior approach than any I've ever seen before. Let me say what I want to say using different words: I feel that Debian has the best *technical* approach to menu systems. The contents of the menu entries is somewhat irrelevant at this stage. Here's how it works: each program that wants to provide a menu entry, provides a so-called "menu" file that contains menu entries, in a sort of meta-data format, for each item it wants in the menu, incl. Categories, etc... additionally, programs like afterstep, flwm, fvwm, windowmaker, and environments like gnome and kde, provide so-called menu-interpreter files, which together with the menu program understand enough of the menu entries to be able to form their *own* menus, in the *own* format. The very strong advantage of this mechanism becomes clearer when one has many window managers, and gnome, kde, or both. No matter which WM or environment they choose, the menu entries are the same and are handled in the 'native' means by their favorite program. I wrote the menu handling code myself for AfterStep, and it has served well for several years. One thing I could always count on with Debain, besides rock-solid stability, was that the menuing system *worked* and it contained almost every relevant user-runnable program in a clear, easily understandable format regardless of which environment or WM I was in. That can be an incredible boon to new users, especially those that are used to the 'start menu' philosophy. -- Pound for pound, the amoeba is the most vicious animal on earth. Jon Nelson C and Python Code Gardener