<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head><body style=""><div>Hi Len,</div>
<div> </div>
<div>No problems with the rant. It summed up the issues pretty well for me. I need to set up my US development VM again and play around with different DE's and the menu to understand better (and catch up with you). Last night I took a little look at your work on the menu in Launchpad.</div>
<div><br>> On 19 May 2015 at 01:37 Len Ovens <len@ovenwerks.net> wrote:<br><br></div>
<div>[...]</div>
<div><br>> Ok, so how does that apply here? Are you saying remove all audio submenus? <br>> Don't add more? The categories in the application desktop files do not <br>> follow anything worth while. Getting them fixed may be possible for some <br>> applications, but often they are not technically wrong. It is why we have <br>> had a custom menu from the beginning. To bring some order to where there <br>> was none. I would suggest that one of the reasons menus are being <br>> abandoned in many DEs, is that the standard is broken/not followed and the <br>> standardized menu is a mess. I have filed the same bug report with 4 or 5 <br>> different DEs where their menu definition does not follow the standard or <br>> meet with the intent of the standard. One of them agreed and the rest <br>> decided it was not broken "won't fix". So KDE (which was right from the <br>> beginning) and xubuntu are correct. lxde, xfce, gnome past and present <br>> etc. do not allow the user to be able to reorder the look and feel of <br>> their menu as they should be able to. If you want something done right... <br>> you have to do it yourself... appears to be where this one sits.</div>
<div> </div>
<div>Personally, I would prefer to work with the standard as far as possible, even if it means carrying patches in Ubuntu and pushing them upstream to Debian, and further to the projects. But this is the long game, and I feel your pain (having experienced non-responsive/slow/resistive upstreams in other areas).</div>
<div> <br>> If I am to make any changes. I need specifics, not vague comments with no <br>> direction. That is why I proposed using a format like above, A diff kind <br>> of format. The reason for putting it here is that others can see it, tell <br>> me it is wrong (and where) and what the better way would be.<br>> <br>> I am quite good at manipulating menus in a way that works with different <br>> DEs. Maybe not so good at knowing what the best layout is.</div>
<div> </div>
<div>[...]</div>
<div> </div>
<div>I think it is fine to carry on with our menu in the medium term. And maybe you are right, that our menu stub will win out in the end. But I was kind of hoping that working on an ideal structure would map reasonably well to all approaches. I was hoping we would end up with a good place for each "default" application in our menu, and then patching the desktop file to match it as best as we can within the constraints. WIth Set's work on the video/publishing categories, we should soon be in a place to try and present it all in some sort of table?<br><br>Cheers,</div>
<div> </div>
<div>Ross</div></body></html>