Community
Participate
Working Groups
Learning from the pattern applied in bug 325392 we can provide similar rendering for toolbars. 1) ToolBarManager that can be craeted by the renderer or linked up. 2) toolbar MMCs can be applied, and their visibility can be controlled in a group and then either by RATs or by a timer 3) changes to the ToolBarManger external to the renderers can be represented in the model without requiring the model to be aware of all of the uses for 3.x PW
Created attachment 190141 [details] work in progress v01 Doesn't do much yet. PW
Created attachment 190379 [details] work in progress v02 ToolbarManagerRenderer now renders the toolbars correctly, and the trim renderer can show them. no drag handlers, however. PW
Created attachment 190436 [details] Render toolbars via ToolBarManager v03 I've kept the current pattern, where the MToolBar renderer returns an intermediate composite. The composite can contain: ToolBar(dragHandle) ToolBar(MToolBar) ToolBar(part MMenu) I'm not convinced the responsibility of maintaining multiple toolbars should fall to this renderer, but I leave it consistent for now. PW
Created attachment 190445 [details] Use the standard toolbar renderer with compat view v04 Removes use of MRenderedToolBar. Needs work to deal with Outline view, switching pages doesn't update correctly as the ToolBar has been disposed, and doesn't want to come back. PW
(In reply to comment #3) > Created attachment 190436 [details] > Render toolbars via ToolBarManager v03 > Released. PW
Created attachment 190507 [details] Use the standard toolbar renderer with compat view v05 This got rid of MRenderedToolBar and the extra disposes. PW
(In reply to comment #6) > Created attachment 190507 [details] > Use the standard toolbar renderer with compat view v05 Released for build PW
Created attachment 190508 [details] link toolbars from the coolbar directly v06 If the coolbar contains a toolbar, allow it to be rendered directly. PW
(In reply to comment #8) > Created attachment 190508 [details] > link toolbars from the coolbar directly v06 > Released to HEAD PW
Created attachment 190509 [details] Allow changes to the coolbar to feed the model v07 work in progress PW
If you switch to the 'Debug' perspective there's this spot in the window's toolbar that shows two separators together.
Created attachment 194484 [details] Allow changes to the coolbar to feed the model v08 In Progress: The ICoolBarManager keeps the model up to date as it is changed. PW
Created attachment 194595 [details] Allow changes to the coolbar to feed the model v09 WORK IN PROGRESS Model appears to be updated regularly, but toolbars are not yet rendered. PW
Created attachment 194774 [details] Allow changes to the coolbar to feed the model v10 Allow the action bars to fill the coolbar, and then convert it to the model. PW
(In reply to comment #14) > Created attachment 194774 [details] > Allow changes to the coolbar to feed the model v10 Released to HEAD. There is still 2 toolbar missing, and editor specific toolbar, and the org.eclipse.ui.edit.text.actionSet.presentation actionSet, which is tied to the active editor PW
text presentation actionSet is back. Unfortunately, so are a lot of separators. PW
Created attachment 194976 [details] Separation and Separator work v11 With the changes to the CoolBarToTrim manager there are now a lot of separators visible. The toolbar renderer doesn't have the correct information or visibility to manage them. This patch is the first pass attempt at breaking up the responsibility: TrimBarRenderer creates an intermediate composite, a drag handled (faked for now), and then renders each MTrimElement in that. This works as expected. StackRenderer/LazyStackRenderer are trying to do the same thing, rendering the part toolbar and part menu into an intermediate composite. I don't have to re-parenting set up correctly yet, however, as it spends its time yacking. PW
Created attachment 195264 [details] Separation and Separator work v12 StackRenderer/LazyStackRenderer now creates a composite to host the toolbar and view dropdown menu button. TrimBarRenderer creates a composite to host the current "fake" drag handle and the toolbar. PW
(In reply to comment #18) > Created attachment 195264 [details] > Separation and Separator work v12 > Released to HEAD Next step is to make sure there aren't 1000 separators in the trim area. PW
(In reply to comment #18) > Created attachment 195264 [details] > Separation and Separator work v12 Needed to re-parent toolbar when MPart refs reparted, to avoid bug 334580 PW
This is finished, now there are bugs that need to be fixed, like bug 345193 PW
