From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 431 invoked by uid 1002); 14 Aug 2003 10:52:38 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 13014 invoked from network); 14 Aug 2003 10:52:34 -0000 From: Chris Gianelloni To: Heinrich Wendel Cc: gentoo-dev@gentoo.org In-Reply-To: <200308140145.55260.lanius@gentoo.org> References: <200308131844.24013.lanius@gentoo.org> <200308140000.47539.lanius@gentoo.org> <1060818426.19250.58.camel@vertigo> <200308140145.55260.lanius@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TYaUnMcKl01exyaYux4h" Message-Id: <1060858593.19236.75.camel@vertigo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 14 Aug 2003 06:56:33 -0400 Subject: Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files X-Archives-Salt: 7818d717-6e3a-43ef-a303-26929ddf583b X-Archives-Hash: c560a228498785623a850bf102dedb72 --=-TYaUnMcKl01exyaYux4h Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-13 at 19:45, Heinrich Wendel wrote: > > the "generated by parser or ebuild" that is simple enough. The parser > > should *never* create files in the "legacy" locations, but only in the > > location where we designate the Gentoo menu system would go. Any files > > in the legacy locations would be placed by the package/ebuild and shoul= d > > not be considered authorative for our menu system, but rather should be > > parsed to *create* our menu system. For example, if I create an ebuild > > that copies a .desktop file to /usr/share/gnome/apps/Internet and call = a > > make_gentoo_menu function at the end of my ebuild, then it should parse > > the file and add it appropriately to the Gentoo menu location. In this > > same token, I should be able to manually create a file in > > /usr/share/applications or /usr/share/gnome/apps/Office or > > /usr/share/applnk and then run a script, say update-menu, and it should > > parse all of the legacy locations and add any new files to the Gentoo > > menu system. Essentially, we should create a new menu system that is > > independent of the others, rather than trying to fix the others. It > > would be fairly trivial to patch the window managers to get their > > information from the Gentoo-created menus as opposed to the intensive > > problem of "fixing" every application that even thinks of installing a > > menu item. This is of course my opinion, but I am trying to keep this > > all on -dev so we can get some good feedback from the users, as they're > > the ones really requesting it. >=20 > How can we make a menu for KDE without writing to /usr/kde/3.1/share/appl= nk or=20 > /usr/share/applnk ??? You don't. Read the part of my comment that I left in this message.=20 Rather than add OUR menu system to /usr/kde/3.1/share/applnk, we should patch KDE/Gnome/*box/etc (actually quite simple) to use /usr/share/gentoo-menu or wherever we decide the Gentoo menu should go.=20 This saves the problem of having to edit every ebuild right now to implement this, allows for a "Gentoo Menu" support which can easily be turned on or off via FEATURES, and gives us a single location for our entire menu structure, rather than duplicating our parsed menus all over the filesystem. After all, if I have Gnome, KDE, WindowMaker, AfterStep, and Fluxbox installed, the current proposal would have to create 5 separate menus and maintain them to keep everything accurate.=20 Under my proposal, it would only have to maintain ONE and all 5 window managers would use it. At this point you can use ANY version of ANY spec we wish to support, and we don't have to wait on anyone else to support it. --=20 Chris Gianelloni Developer, Gentoo Linux --=-TYaUnMcKl01exyaYux4h Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/O2rhkT4lNIS36YERAp6yAKCFchiqxXeuazCztnNfLCFBBfs/vgCgipz8 gBGjZV6S82fopBmpVLNldrw= =sjhW -----END PGP SIGNATURE----- --=-TYaUnMcKl01exyaYux4h--