GNOME Bugzilla – Bug 86322
Menu editing super bug
Last modified: 2004-12-22 21:47:04 UTC
The issue of menu-editing encompasses gnome-vfs, gnome-panel, nautilus, eel and probably a few other modules. Therefore I have opened this bug as a placeholder for all of the various issues, as I have done loads of investigation. I have cc'd to the three main maintainers.
As has been discussed menu editing has been temporarily disabled for gnome 2.0 The current situation as I see it is The basic system is now functioning - ie:vfolders, desktop files, .directory files. However I think the problem is actually in the code for creating/editing menu entries. The code at present seems to not create a "Categories" entry so gnome- vfs does not know where the .desktop should go. As the same code is used for the panel and nautilus applications, this would probably fix the remaining problem #73773 seems to be a purely gnome-vfs issue as there does seem no way to create/edit categories from the gui.
I now think I know where the main problem comes from All of the menu edit/create stuff comes from the code to create a launcher on the desktop Initially the launcher code did not have any function to add a categories line because not strictly neccessary for the desktop. However this same code was used for the panel/nautilus create/edit menus stuff. So the solution IMHO is (cant code C I am afraid) is to alter the code to 1. look for a categories line 2. If it is not there, add the line 3. For legacy apps, look at the path of the .desktop file and do some translation eg: /Internet/mozilla.desktop to Application;Network
Urgh. I hate not just closing this, but... has to be done.
String an ui string freeze is a week away. Nothing positive seems to have been done on menu editing as yet
Obviously it has been decided that menu editing is NOT to be implemented at all for some reason This is the only possible conclusion as since 2.0, all vestiges of the menu editing code have been removed not one menu editing bug has been touched properties has been removed from the menus So the question is why is this bug still triaged as 2.01, if there is no intention to have menu editing, all related bugs may as be closed with a WONTFIX Also can anyone explain any reason to maintain an up-to-date less functional gnome2 environment? Yes I know it is free software, but I was under the impression that gnome was supposed to have some sort of development process, which triaging of bugs was part of.
Mike, you're not helping. Insulting our development process won't get anything done faster. Please consider either helping to fix the problem or just letting us work without a constant stream of complaints and insults.
Duh - constant stream? - your definition must be different to mine I have mailed twice to desktop-devel, annoted this bug a couple of times Hate to remind you but it was mainly me who wrote the release notes about menu editing My web page about menu editing gets about 12-13MB a day, showing there is a need My point stands though - if this is not going to be in 2.0.1, and the development has gone in the opposite direction, all menu bugs should be marked as WONTFIX, so at least people know that if they want to be able to edit menus, they should not update gnome-panel and nautilus Thought I was on gnome, not KDE
Hate doing this - but from the comments I have recieved this is not regarded as anything significant so need to to close this as WONTFIX so at least people realise that it wont be fixed Very sad
There are people working on this problem. In general you should leave WONTFIXing to maintainers. "Won't be fixed for 2.0.1" is not the same as WONTFIX. Even if it were certain that this wouldn't be fixed for 2.0.1, resolving as WONTFIX would be the wrong course of action. This is the only bug related to this issue that I happen to be CCed on, please reopen any other bugs you have closed.
>>There are people working on this problem. Not to my knowledge - and I have been flamed a few times for reminding people about this issue >>In general you should leave WONTFIXing to maintainers. My bug - and my impression has been this is a wont fix >>"Won't be fixed for 2.0.1" is not the same as WONTFIX. Even if it were certain that this wouldn't be fixed for 2.0.1, resolving as WONTFIX would be the wrong course of action. I have prompted about this issue a few times and have either had silence, a lecture about free software or "please go away" comments (see Additional Comments From Dave Camp 2002-07-16 08:49 ------- above) >>This is the only bug related to this issue that I happen to be CCed on, please reopen any other bugs you have closed. I dont close bugs that are not mine! I feel this is a very important issue as regards usability (I know not every ones interpretation is the same) and the only progress I have seen since 2.0 has been to remove any trace of menu editing functionality with no comments on 73770,73773 or this bug - also the situation with properties see #85622 As I have said before http://www.redtux.demon.co.uk/docs/gnome_menu_edit_doc.20_6.html Menu editing on my system works pretty much perfectly (hacked gnome-panel-2.0.1) My major problem is that I did a lot of work in finding and reporting the problem and since 2.0 the only work apparent has been to remove any functionality in editing/manipulating menus Nothing would please me more than to see this issue addressed, but if it isn't being it is pointless to have an open bug
Mike: Alex Gravely (alex@ximian.com) is working on this, here at Ximian, and I am helping out a little. It will be sorted out in the next few weeks. Our new vfolder code is in the gnome-2-0-vfolder-rewrite branch of gnome-vfs. If you want to help test that out it would be great. I think it is still missing a few important features, though, so maybe wait a bit until it is feature-complete.
are there equivalent eel, nautilus and gnome-panel branches
Where do I report bugs on the rewrite branch? I tried it last night and it wiped all my menus - I think it must be related to change of format of applications.vfoldeer-info - will investigate further.
Comments on vfolder rewrite branch 1. Since I installed - chronic X instability 2. Menu structures really mangled see ht 3. Different keywords seem to be being used and missing categories such as system
sorry - link shouldf be http://www.redtux.demon.co.uk/docs/screenshots/gnome-vfs-rewrite-menu.png
But does menu editing work? :)
After a fashion - but a lot worse than the former gnome editing Reasons - impossible for a normal user to change the name of the launcher Creates entries in .gnome2/vfolders but ignores them Still not possible to rename a folder
Further comments on vfolder-rewrite Files are being created in ~/vfolders/applications, but are not being looked up by gnome-vfs so do not appear in menus Renaming menu categories/folders does not work - after renaming dissapears from applications:///
Further comments on vfolder-rewrite Files are being created in ~/vfolders/applications, but are not being looked up by gnome-vfs so do not appear in menus Renaming menu categories/folders does not work - after renaming dissapears from applications:/// Also briefly flashes up a no permissions emblkem before dissappearing
The preferences-allusers.vfolder-info file includes a merge line for 1.4 control-center capplets which should not really be there - it makes a mess of the advanced menu
If anything, it should just exclude those capplets which have gnome2 replacements. In either case can you create a new bug for this mike?
*** Bug 90456 has been marked as a duplicate of this bug. ***
*** Bug 91114 has been marked as a duplicate of this bug. ***
Closing since all its dependencies are closed. I guess you should use individual bugs from now on, or add them as dependencies here and reopen.