Bug 311796

Comment 1 Brian de Alwis 2010-05-06 09:17:51 EDT

Created attachment 167300 [details]
Work in progress

This is a first cut, but I'm not very happy with it.  Basically I've redistributed the toolbar population and placement work from StackRenderer to SWTPartRenderer and ToolBarRenderer.  

In trying to refactor this, I wanted to avoid anything but the ToolBarRenderer from assuming that the MToolBar is rendered as an SWT ToolBar (I'm contemplating replacing the toolbar renderer in my own app with something that supports button strips).  Unfortunately a part with a view menu but without a toolbar requires a toolbar to be created to hold the toolitem to generate the view menu (ick).  I'd prefer to spoof up a MToolBar for this case, but then that toolbar would be persisted to the delta; it's almost like we should have a "transient" tag.  I suppose the view menu item could be rendered instead as a flat button instead.

Comment 2 Brian de Alwis 2010-05-06 09:25:32 EDT

Created attachment 167301 [details]
Eclipse CVS-friendly version of the patch

Regenerated using the Eclipse CVS patch

Comment 3 Lars Vogel 2014-02-06 09:05:45 EST

Brian, is this still relevant after 4 years?

Comment 4 Brian de Alwis 2014-02-10 11:41:52 EST

I'll mark it as WONTFIX.  It's not a problem inherent to the modelled UI, but to our implementation: part toolbars are only rendered by a part-stack renderer.

And I'm not sure if I want the behaviour to change.  For example, I use a variant of the "Java Browsing" Perspective that sets up the project/package/type/methods views as standalone views to maximize screen real-estate.  The part toolbars aren't shown, since the parts aren't hosted in a stack, and so I have more real-estate for showing meaningful data.