GNOME Bugzilla – Bug 641148
Drop gs-applications.menu and use gnome-menus' applications.menu
Last modified: 2011-02-25 23:11:50 UTC
It's a bit weird that gnome-shell ships its own applications.menu instead of using the standard GNOME one. If the standard GNOME one needs to be updated to accomodate some specific needs, then let's update it in gnome-menus instead of having two applications.menu files :-)
Created attachment 179794 [details] [review] Drop gs-applications.menu so the standard one is used
Also related to bug 638271.
Review of attachment 179794 [details] [review]: Patch looks good.
Wait wait wait. It was introduced for a reason - we need an analysis of the situation, not a blind removal. Originally we wanted to avoid categorization which wasn't part of the design, then it got readded. So indeed, maybe it makes sense to do so. But this needs to be explained in the commit message at least, and better discussed here. (Please don't make git commits that simply say *what* you did. People looking at it later, and in fact reviewing the commit now, need to know **why**, and in this case "it looks like a duplicate" is OK, but doesn't give me confidence that it was tested and made sense given historical context).
For what it's worth, I discussed the patch with Jon and Owen before approving it (I agree with the need for a better commit message though)
Okay, makes sense - I didn't have that context.
(In reply to comment #4) > Wait wait wait. It was introduced for a reason - we need an analysis of the > situation, not a blind removal. > > Originally we wanted to avoid categorization which wasn't part of the design, > then it got readded. So indeed, maybe it makes sense to do so. > > But this needs to be explained in the commit message at least, and better > discussed here. I have absolutely no context about the use of categorization in gnome-shell, so I'm not sure how I can explain things better. What kind of explanation would you expect?
The custom menu file was originally introduced to implement a very loose grouping of applications into three sections ("Apps", "Games" and "Utilities", though those labels didn't appear anywhere, there was just a subtle separator between the sections). After the overview relayout, "proper" categories were re-added, at which point the custom menu file was merely used to tweak the categories a bit (rename "Sound & Video" to "Multimedia"(*) and merge some "more obscure" categories into "Other" ("Programming", "System Tools", "Universal Access") ... While it didn't make any sense for the traditional menu to stuff everything into three very loosely defined categories, this has changed with the re-addition of categories in the shell - if the designers want to adjust the existing categories, it makes now sense to share those with the fallback mode, e.g. share the same menu file between both modes. (*) Jon actually prefers "Sound & Video", the renaming was done because it matched Jakub's mockup at the time
(In reply to comment #7) > > I have absolutely no context about the use of categorization in gnome-shell, so > I'm not sure how I can explain things better. But "git log" will give that to you. > What kind of explanation would > you expect? In this case just something like: "In bug 614131, limited categories different from GNOME 2 were introduced. Now that we've backed off and moved closer to the original GNOME 2 categories, drop the custom category file and use the one from gnome-menus." I'm not trying to flame and actually I'm glad this file dies, since it was an ugly hack =) I'm just a stickler for good commit messages.
(In reply to comment #9) > I'm not trying to flame and actually I'm glad this file dies, since it was an > ugly hack =) I'm just a stickler for good commit messages. Oh, I didn't take it as a flame. Thanks, I've added some better message based on yours.
And I've added a stub at http://live.gnome.org/GnomeShell/Design/Whiteboards/AppCategories in order to look into having less crappy categories at some point.