From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31515 invoked by uid 1002); 13 Aug 2003 23:43:00 -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 25116 invoked from network); 13 Aug 2003 23:43:00 -0000 From: Chris Gianelloni To: Heinrich Wendel Cc: gentoo-dev@gentoo.org In-Reply-To: <200308140000.47539.lanius@gentoo.org> References: <200308131844.24013.lanius@gentoo.org> <200308132316.56438.lanius@gentoo.org> <1060811401.19236.42.camel@vertigo> <200308140000.47539.lanius@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0162Q6FIVtY+6vkCn4zG" Message-Id: <1060818426.19250.58.camel@vertigo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 13 Aug 2003 19:47:06 -0400 Subject: Re: [gentoo-dev] Gentoo Menu - Bash vs. Python Rule files X-Archives-Salt: d5e8fc57-8f82-4d39-a0bc-002ad6c3b91c X-Archives-Hash: 278e2b69abb2671fd68e214b78fe5e54 --=-0162Q6FIVtY+6vkCn4zG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-13 at 18:00, Heinrich Wendel wrote: > You are right, it takes a lot of work. But the problem is that we want to= have=20 > flexible menus, via the menu-spec. How should this transparent parser kn= ow=20 > in which category it should put the entry? The gnome/kde categories are n= ot=20 > compatible with the categories listened in the menu-spec. And how can you= =20 > know that the entries in /usr/share/applnk are generated by our parser or= by=20 > an ebuild? First off, using a spec that is not in use but will be in use is rather pointless, as you are doing WAY more work than need be done. The better way to go about it would be to create optional support for the new specifications and build to the current implementations. I, quite personally, couldn't care if this is the way things are "going to be" in KDE/Gnome/*box/etc. I only care how they are now. Create some conditionals which check for versions and match themselves to that specification. The menu structure should fairly well match what is being put out by the upstream maintainers as well as possible. As for 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 should 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 Chris Gianelloni Developer, Gentoo Linux --=-0162Q6FIVtY+6vkCn4zG 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/Os36kT4lNIS36YERAhKDAKCuyl86XsOjFRl1WZjovVCUoNjAkACeN6Rg Pv0znilCf9kmXeOrxGAI0Pk= =5h8Q -----END PGP SIGNATURE----- --=-0162Q6FIVtY+6vkCn4zG--