Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 496678

Summary:	Investigate ways to simplify the definition / customization of menus / toolbars
Product:	[ECD] Orion	Reporter:	Eric Moffatt <emoffatt>
Component:	Client	Assignee:	Eric Moffatt <emoffatt>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	libingw, snorthov
Version:	12.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:
Bug Depends on:
Bug Blocks:	457886

Description Eric Moffatt

2016-06-23 13:24:18 EDT

Folks using Code Edit are asking for mechanisms to customize the menus that appear in their instance(s) of the editor. The current API (registerCommandContribution and addCommandGroup) are very arcane (i.e. having to define the full 'path' for every registered item...) and require that the person defining the items be aware of the integers used as 'positions' in the existing definition.

The first cut at this is to see whether we can take a menu 'structure' (an JSON'able Object containing a structure consisting of commands and group definitions and have that structure translated into the existing API calls.

I already have the basic implementation in a branch of the client - 'JSONMenus'.

I'll be working with Libing to see how this will integrate into the existing Code Edit mechanisms...

Comment 1 libing wang

2016-06-23 13:33:26 EDT

org.eclipse.orion.client.ui/web/embeddedEditor/demo/demoCodeEdit.html will be something we can start with. I t consumes the non built version of the widget and I've already creates a separate DIV ,trying to render all the commands. Also, we should think about the editor context menu as well.

Comment 2 Eric Moffatt

2016-08-05 13:48:15 EDT

OK, I've just pushed (into the 'MenuStructs' branch) code that:

1) removes any need to have a 'handler' defined in the menu structure (meaning it's JSON'able again).

2) greatly simplify all 'visibleWhen' and 'callback' methods for editor commands to never reference the 'data.handler' field (visibleWhen impls) or 'this' (callback impls).

I've checked to ensure that the result correctly handles multi-editor cases (including GIT diffs) to ensure that we haven't regressed anything.

Comment 3 Eric Moffatt

2016-08-05 13:49:01 EDT

Libing, next week we should work out how to allow Edit Code to hook into the new mechanism...

Comment 4 Eric Moffatt

2016-08-29 13:34:28 EDT

OK, I've updated the 'MenuStructs' branch...

At this point everything has been switched over to using the menu structure for each of the Edit / Git & Compare pages with the following exceptions:


GlobalCommands are handled by a local change in the file that defines its 'struct'

OperationsDialog defines its own 'cancel' operation (TBD)

Git Page:

CompareCommands#197: has 'toggleCommandSpanId' (move to the specific menu structs git vs compare ?)
resourceComparer#264 Save command needs handler


Compare Page:

CompareCommands#197: does *not* have 'toggleCommandSpanId' (move to the specific menu structs git vs compare ?)
Save command still handled the old way because it needs a handler (change visibleWhen / order of creation to match the Git page (where the simplified visibleWhen works correctly.

Edit Page:

Tools Menu Extensions...EditorCommands#318...
Editor Context Menu Extensions...editorCommands#362

sidebar registers the 'propblemsInFolder' command (Twice)  (move to 'toolsActions' struct)

setup@1093 registers 'splitMode' to 'settingsActions'

common-nav#375 OpenWith, FileCommands and new ProjectCommands extensions

filesystemSwitcher#77 registers a mini-nav "orion.nav.switchfs"

outliner#528 registers "Sourece Outliner" to viewActions at "orion.menuBarViewGroup/orion.slideoutMenuGroup"

Comment 5 Steve Northover

2017-03-30 12:09:42 EDT

Eric, you worked on this a while back.  Did the changes ever get in?  We (as a group) need to decide whether we are better off with the code or without it.  

The final word is a Silenio/Steve decision and we just need to make it once we have the information.

Comment 6 Michael Rennie

2018-04-09 09:37:29 EDT

Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. 

For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04114.html