From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1159 invoked by uid 1002); 14 Aug 2003 12:51:53 -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 29922 invoked from network); 14 Aug 2003 12:51:52 -0000 From: Chris Gianelloni To: Heinrich Wendel Cc: gentoo-dev@gentoo.org In-Reply-To: <200308141408.43807.lanius@gentoo.org> References: <200308141408.43807.lanius@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XD6E8OMHkZuMnAjHoN83" Message-Id: <1060865750.19236.167.camel@vertigo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 14 Aug 2003 08:55:50 -0400 Subject: Re: [gentoo-dev] Gentoo Menu - Summary X-Archives-Salt: ef60ea74-1524-4524-8322-e69335229114 X-Archives-Hash: 1f75689ff0b30e72da81f19959e82199 --=-XD6E8OMHkZuMnAjHoN83 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-08-14 at 08:08, Heinrich Wendel wrote: > 2.) There are ppl that say, the proposed solution is to much work, why no= t=20 > base on the current situation and create a wrapper around the gnome and k= de=20 > menus. But what will we do if KDE or GNOME changes it menu-system, we hav= e to=20 > change ours as well. The proposed solution will be completly independent = from=20 > KDE and GNOME. I also want to qoute spider: I believe I was more thinking not that it is too much work, but rather too much *pointless* work. I do not feel we should be changing literally hundreds of upstream packages to make them put their desktop entries in the location we want, then have our menu system generate the legacy menus for each window manager. I think it would be much simpler to leave the current window manager's menu system alone and create our own. For example, Gnome uses /usr/share/applications as the location for menu items in version 2+. It uses /usr/share/gnome/apps for versions below that. The new versions still have support for the old style menus to allow older applications to be in the new Gnome menu. Now, I have USE=3Dmenu in my make.conf and I emerge gnome. This applies a SINGLE patch to the gnome-panel ebuild which changes the default location of the Gnome system menu to /usr/share/gentoo-menu, where we store our Gentoo-created menus. Now, when gnome-games emerges, it puts all of its .desktop entries in /usr/share/applications. At the end of the ebuild, a do_menu function is run which takes the .desktop entries added by the gnome-games ebuild and parses them. It then creates entries in the /usr/share/gnome-menu directory which meet our menu specifications. This way, if USE=3D-menu, NOTHING has changed for the user. > "consider that we don't have to provide massive fileupdates, global lists > coherent with our tree, but each capable and installed package requires > a small change that goes back and forwards with versions without > overhead for versionbumps." I see no reason to change hundreds of application ebuilds, when changing the window managers themselves is much simpler and more succinct. Yes, the application ebuilds will have to be modified to add the do_menu function, but I have no problem with this simple change which makes no real changes to the actual upstream package, rather than changing the locations of where a package chooses to install its desktop entries. I may be misunderstanding exactly how your proposal is designed to generate the menus, but I see mine as extremely unobtrusive to both the developer (or user) creating the ebulds, and also to the end-users who choose to NOT use our menu system. > 3.) Implementation issues, like icons, we can discuss that later. Agreed on that. I just wanted to point out that there is already a default location for "default" icons. Icon themes are handled differently by each window manager. (Uh oh, I see another proposal coming up... ;p) > And finally i want to quote seemants post ;) >=20 > "Wow, this thread is just getting silly. For the nay-sayers who just > want to "add my own menu entries, thank you" have you actually READ what > the proposal was? Did you not see that the thing is optional? Further, > did you not see that it will NOT overwrite the application's native menu > stuff? >=20 > For the developers who won't go and change their ebuilds -- are you sure > you've got the end-user's best interests at heart? Having been part of > the distro for damned near 20 months now, "why doesn't gentoo have an > automated menu system?" is among the top 10 most frequently asked > questions. If you won't switch them, we'll find a developer who will. >=20 > Please, stop this flame rubbish already." I don't think any of us are considering denying the users of anything.=20 However, I think we (well, at least I) are wanting to just have more discussion and much more input on how this would be implemented to try to accommodate as much of the user base as possible. --=20 Chris Gianelloni Developer, Gentoo Linux --=-XD6E8OMHkZuMnAjHoN83 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/O4bWkT4lNIS36YERAm/rAJ40WG/fr+bPHTpwprMgtamr/ZxxRACfVxSb EMbQi5QFR5kNRR2M22QF7m8= =NNNr -----END PGP SIGNATURE----- --=-XD6E8OMHkZuMnAjHoN83--