Re: [gentoo-dev] Gentoo Menu - Summary

[Chris Gianelloni]

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 not
> base on the current situation and create a wrapper around the gnome and kde
> menus. But what will we do if KDE or GNOME changes it menu-system, we have to
> change ours as well. The proposed solution will be completly independent from
> 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=menu 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=-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 ;)
>
> "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?
>
> 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.
>
> Please, stop this flame rubbish already."

I don't think any of us are considering denying the users of anything. 
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.

-- 
Chris Gianelloni
Developer, Gentoo Linux