Community
Participate
Working Groups
Investigate using CoolBars instead of ToolBars in the eclipse ui code. As part of this, make sure keyboard support exists for the CoolBar.
Looked into this some and after talking to Nick I don't exactly understand what you want, so you need to specify.
Also need to consider how this is going to be integrated. We can't just change JFace to use CoolBars vs. Toolbars since JFace is public.
KH states: The objective (for 2.0) is to allow editors like the HTML editor, which have tons of toolbar items the ability to add/remove/rearrage groups of toolbar items. I am not as interested in changing the size of toolitems or rearranging them within a group as we would also have to persist this information and does not contribute to improved usability of the product.
We need to look into supporting multiple toolbars, rather than having dynamic rearrangement of a single toolbar. The HTML editor could then define its own toolbar for the HTML element insertion actions (paragraph, list, ec), and perhaps another for formatting actions (bold, italic, etc). In the short term the main toolbar (the current one) will be dynamic (as it currently is) when new action sets or editors are activated, but we should try to get away from dynamic toolbars. I propose pushing ahead with coolbars, as follows: - use coolbars for the toolbars only - leave the menubar as a standard menubar for now until we get SWT support for this (problem areas include accelerators and OLE) - use a single coolitem for the current toolbar (don't try to break it up) The next step would be to break up the current toolbar and have a separate toolbar and corresponding coolitem for: - the hardwired workbench actions, - each enabled action set, and - the editor contributions (still dynamic, though). Eventually the editor contributions could be done more statically, e.g. define a separate toolbar for the type of editor, with a fixed layout, and allow editor types to specify their preferred toolbar(s). We should try to make any changes to JFace be backwards compatible. One option would be to add a flag on ApplicationWindow as to whether to use coolbars or not (default would be not).
See bug 11369 for SWT work on coolbars needed to make this real.
Basic implementation in. Outstanding items: - When chevron added, make the associated tool item invisible. Asking CM to do. - Figure out how to get ToolItems with drop down menus to work in the CoolBar chevron menu. NE thinks menu manager should handle this. Need to investigate. - Work out weird layout actions. CM investigating. This includes the unexpected "slide to the end" behavior. Happens when moving CoolItems and happens under certain circumstances when you add a CoolItem to an existing CoolBar. Need to come up with test case for CM for latter issue. - Currently editor action cool items not working as best as they could. The scenario is as follows: 1. Go to Java Perspective. Open a *.java file. Arrange the cool items so that the editor cool item is somewhere in the middle of the CoolBar. 2. Go to Resources Perspective. Open a *.class file. Close the *.java file. 3. Go back to the Java Perspective. The class file editor cool item does not get put in the place of the java file editor cool item - Save and restore coolbar layouts between workbench sessions. - Code cleanup. - Linux. Suggest that we just leave it with a ToolBar.
On Friday I noticed that new cool items don't seem to honour the lock setting. Also, we should change the lock setting to be global (apply to all perspectives).
Created 14330 for add new items and locking problem.
Workaround released for 14330. Changed Lock the Toolbars to apply to all perspectives. Introduced IWorkbenchWindowPulldownDelegate2 to handle chevrons and drop down tool items.
PluginActionSetBuilder needs to work for a CoolBarManager. Doing this will resolve ordering issues with workbench CoolItems.
Created SWT PRs for remaining issues (on windows): [Bug 15237] New: Coolbar - corrupts wrap layout when items deleted [Bug 15239] New: Coolbar - when chevron appears hide tool icon if partially displayed [Bug 15242] New: CoolBar - layout issues
Released code for ordering issues.
Released changes for saving layout and restoring between workbench sessions.
Opened [Bug 15488] New: EditorActionBars and switching between perspectives problem. This PR is causing undesirable behavior with CoolBars and layout restoration when switching between perspectives.
Opened [Bug 15565] New: Coolbar - minimumWidth not honored under certain conditions Can change my code to work around this now that I know the conditions under which it occurs.
Opened Linux SWT PR: [Bug 15989] Coolbar walkback when adding item
Workaround provided for 14330, so there is no longer a dependency there. Closing this PR. Coolbars were provided for F1.
