MenuManipulator 20080929

[dorando]

This extension allows you to move, edit, or create new <menu>, <menuitem>, and <menuseparator> elements within a <menubar>, <popup>, or the <tabbrowser>s context menu.

Moving happens via drag and drop, everything else (currently) via right clicking on the menu or attribute pane.

MenuManipulator should work with Firefox, Thunderbird, Sunbird, Flock, ChatZilla on XULRunner, and Toolkit 1.9 Applications (Prism, Songbird, McCoy, the upcoming SeaMonkey 2.0, ...).

Gecko Bugs / Limitations:
- Moving a node will cause the attached event listeners to be lost (bug 286619. In most cases it should be possible to modify the corresponding attributes to make the appropriate function calls.
- Setting some specific attributes corrupts the .attributes list (should be harmless in most cases).
- Setting attributes which are <observe>d (maybe from a <command>) will likely fail.
- User created Top Level <menu>s without a style attribute are invisible as the core (incorrectly) assumes that they are empty.

Notes:
- Future version might not be backward compatible.
- If an extension (or an app update) adds/removes <menuseparator>s or <menu><menupopup> constructs without an id, some actions might be applied to the wrong items.
- Neither its design nor the way it works allows the MenuManipulator dialog to be moved into the Option dialog. Neither should it be an extension option dialog as it is a tool for editing the application not for editing MenuManipulator specific prefs.
- The MenuManipulator dialog tries to avoid generated menu items as these can mix up move actions, but since there is no easy way detecting these, some might still be listed.
- If you disable an extension which adds menu items, it is advisable to reset these specific items or there is a chance that some move actions are misinterpreted.
- If you change more than a few items, Menu Editor might be a better alternative.

Configurations:

Code: Select all

prefs.js:

// Set the number of fallbacks the Move action should use
user_pref("menumanipulator.Move.fallbacks", 0);

// Determines if the state of an item should be saved along with other edits
user_pref("menumanipulator.saveState", true);

// Code which will be run in every window
user_pref("menumanipulator.global.20080606", "Module('UIHook');");

// Module('UIHook'); adds a menuitem to all windows matching this pref
user_pref("menumanipulator.UIHook","");

Changes:
20080929:
- Minor workaround because Firefox 3.0.2 changed a "~10 year old behavior in a breaking way"
- Minor workaround for builds without the change for bug 312867 (ChatZilla! on XULRunner/1.8.0.9)
- Opening MenuManipulator doesn't reuse the existing window anymore as this caused problems. Opening multiple instances to edit the same window is still not advisable
- The context menu key should now work as expected

20080606:
- Added support for Toolkit 1.9 Applications and dropped support for pre Toolkit 1.8.
- Minor fix to make MenuManipulator work correctly in ChatZilla!
- Collapsed state should now be remembered (set menumanipulator.saveState to save it along with other changes)
- Empty actions shouldn't be saved anymore
- Minor change to the component to avoid a possible leak
- Double clicking an attribute will now allow it to be edited
- Editing an attribute now opens a multi line editor
- Editing the label attribute will be reflected in the tree
- Moved one line of code to the Service Constructor since the app-startup observer doesn't seem to be called in Gecko 1.9 if addObserver has not been called before
- Added a workaround for problems introduced by 254021
- Added a pref (menumanipulator.global.20080606) for code which will be run on every window. Moved some code there (tab context support, simple XPath interpreter, UI Hook) only loaded by applications needing it (will be set on first run)

Older Changes.

[Tene]

In the hope this'll work using the latest trunk, I'll try it ... btw what about "Menulator"? Sounds very retro 8)

Edit: stupid me, didn't notice that it didn't delete (well, until I found out first hand).

[dorando]

In the hope this'll work using the latest trunk

It works.

didn't notice that it didn't delete

I did not implement a method to delete items as this can cause problems. If you want to hide an item use the <a href="http://www.mozilla.org/support/firefox/tips#app_mainmenu">built-in</a> functionality or set <code>style</code> to <code>display:none</code> of the specific item.

[Worldseye]

Does this extension coniflict with Menu Editor?.. I'm guessing it does, but wanted to ask, as with them both you'd have complete control.. next question.. any plans to combine this extension with Menu Editor?

[jedbro]

Awesome!

[dorando]

Does this extension coniflict with Menu Editor?.. I'm guessing it does, but wanted to ask, as with them both you'd have complete control.. next question.. any plans to combine this extension with Menu Editor?

MenuManipulator is an alternative approach to the same core functionality provided by Menu Editor, so yes it will conflict with it (you shouldn't have a need for it anyway)....

[Zoolcar9]

I'm still using MenuEditor 1.1, and it works with MenuManipulator

[Ebu]

Hi!
I tested MM and liked especially the funktion to add new menus.
But I've got one question: Is it possible to copy items of menus? I'd love the possibillity to create a new Menu (as the 'tool' menu) with the options I like and need. But I don't want to 'cut' them from their original position. Think that would be cool.

Thanks so far,
Ebu

[hydreux]

just wondering, where does the ext. save the changes made to the menubar?
i made some changes then unistalled the ext. & the menubar reverted to the original form...
is it possible keep the changes even after uninstalling the ext.?

attaching the changes made...
<a href="http://img78.echo.cx/my.php?image=menumanipulator4dw.png"><img src="http://img78.echo.cx/img78/6550/menumanipulator4dw.th.png" border="0" alt="" /></a>
Image hosting by ImageShack

[dorando]

I'm still using MenuEditor 1.1, and it works with MenuManipulator

This will eventually lead to problems...

Is it possible to copy items of menus?

I'm considering adding the ability to clone and/or copy nodes, but this likey will cause some issue. For the time being, the only way is to recreate the wanted menu items.

just wondering, where does the ext. save the changes made to the menubar?

In the prefs as menumanipulator.<i>location</i>. Without the MenuManipulatorService this isn't of much use.

[thorazine]

I tried this, I've use MenuEditor before, but resetted menus and edited menuedit.rdf and installed this one and found no problems.
Can this be used safely without breaking anything to create context menu child entries? (This is something MenuEditor cant do AFAIK).
I dont understand what most of the known bugs / limitations mean, say, what items can or cant I move? Can I add / delete separators?

[dorando]

Can this be used safely without breaking anything to create context menu child entries?

I hope so.

[...] what items can or cant I move?

All items listed should be movable, but moving some item with an eventListener (like the Greasemonkey menuitems) or their containers will cause these eventListener to be lost.

Can I add / delete separators?

Adding: yes, deleting: no (but you can hide it by setting <code>style</code> to <code>display:none</code>).

[korsch]

Will this extension (or any other method) allow me to hide options on the Bookmarks Context Menu, such as the 'Sort By Name' option (I hit this by accident sometimes)??

Thanks.

[dorando]

Use

Code: Select all

menuitem[label="Sort By Name"], menuitem[label="Sort By Name"] + menuseparator
{ display: none !important; }

or

Code: Select all

#bookmarks-context-menu menuitem[command="cmd_bm_sortbyname"],
#bookmarks-context-menu menuitem[command="cmd_bm_sortbyname"] + menuseparator
{ display: none !important; }

in your userChrome.css

Editing the Bookmarks Context Menu won't be supported by MenuManipulator as this menu is (re)generated on demand.

[korsch]

That worked for me, thanks very much!