Community
Participate
Working Groups
The toolbar associated with each part is managed by the workbench internals and not by the presentation. The presentation can only alter the toolbar's size and location. Properties such as the background color, foreground, and font cannot be accessed because the Control available in IPresentablePart is not the toolbar itself, but a wrapper instead. Ideally, the presentation could be able to decide whether a ToolBar even makes sense or whether a seperate UI for the actions is desirable.
Bug 82523 seems related.
Ideally, the part should describe what it wants on the toolbar and the presentation should create the widgets for it. This would mean that each StackPresentation that contains a part may use a different widget for that part's toolbar. This is not an easy code change, since views and editors can gain access to the actual toolbar widget through their contribution items, and many of them hang onto it... preventing it from being destroyed and recreated, and preventing there from being more than one widget for the same contribution item. The UI team does not have time to address this issue at the current time. If you are interested in working on this issue, please let me know.
As a short-term solution, could the setFont(), setBackground() and setForeground() methods on the Composite "wrapper" for the toolbar, delegate out to the actual toolbar? That way I would be able to actually change the background color of the toolbar (what I'm trying to do, similar to Bug 82523).
Exposing those methods would be problematic. It would change the toolbar color in all perspectives that contain the view, and the APIs would be need to be broken if the presentation gets the power to actually create the toolbar widgets. Another possiblity: IPresentablePart could gain API that describes the items it wants on its toolbar (but does not actually create them). The presentation could then create whatever widget it wants for the toolbar. In order to maintain compatibility with existing ContributionItems, the actual view would need to convert its existing toolbar to the new API. This could be done by creating an invisible ToolBar in which the view could create its items. The new API could forward events to the hidden widget by using SWT's notifyListeners API.
Those methods are already exposed. The IPresentablePart interface has the getToolBar() method which returns a Composite with those methods. I'm simply asking for them to be delegated through to the ToolBar inside that Composite. As for the other possibility that sounds good, but I'm still a little fuzzy on where the actual ToolBar reference is leaking through.
Is this still a problem in 3.3? PW
I'm not following the presentation changes for 3.3, but for this bug to be resolved would require the toolbar representation to be moved into the presentations API. In 3.2 and previous, the way to add toolbar items was to use IPresentablePart.getToolBar which returned the toolbar that was already created and populated by the workbench internals. Instead, there needs to be some new way to access the contributed actions from within the presentation API that allows it to render those action however it wished.
There is work going on right now to allow finer contribution control to menus and toolbars, but there's no one looking at the presentation API for 3.3. It looks like the presentation API will still only be responsible for placement of the view pane, view menu, and view toolbar, not their rendering. PW
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
The PresentationAPI has been deprecated with the Eclipse 4.x release and it has been replaced with the CSS engine. I therefore close this bugs as WONTFIX. In case your bug report is still valid for the Eclipse 4.4 release, please open a new bug report for it.
