Bugzilla – Full Text Bug Listing
| Summary: | [RCP] Need access to view toolbar from presentation | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nick Edgar <n.a.edgar> |
| Component: | UI | Assignee: | Stefan Xenos <sxenos> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | eclipse, ed.burnette, hudsonr, Matthew_Hatem, michaelvanmeekeren, n.a.edgar |
| Version: | 3.0 | ||
| Target Milestone: | 3.0 M9 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Nick Edgar
This lines up with some of my other commitments for M8. At the very least, I hope to allow the presentation to control the position of the toolbar in the next few days. Okay... I've got a patch working that gives access to the view toolbar, and I've updated the new look presentation to align the view toolbar with the tabs when there is extra space. There are still a few problems with the new look changes, though. 1. The vertical gradient at the top of CTabFolder doesn't work with toolbars. I had to change it to a horizontal gradient (I recommend using a flat color). 2. The tab area has been shrunk recently, and it now truncates the bottom of the toolbar. The API is pretty simple: IPresentablePart has a getToolBar() method, which returns the view's Toolbar instance. The Presentation can move it around, change its colour, etc. Created attachment 8649 [details]
Patch for org.eclipse.ui.workbench
I haven't committed this to HEAD because the view menu is currently broken, and
there is a lot of ugly code that is still visibly "in progress"...
However, this patch should run reliably enough to start fixing the theming
issues (above) and to get some feedback on the new API.
Although the presentation can now manipulate the toolbar, I still need to
create a factory method to allow the presentation to create the toolbar.. but
if moving the toolbar and changing its colour is enough for M8, I suggest that
we defer the rest until M9.
Adding Kim... she's probably best able to address the theme issues in comment 2. Created attachment 8650 [details]
Screenshot showing toolbar manipulation in action
Personally I think it looks fine with either a horizontal gradient or a flat color, but that decision isn't really mine. (I own the engine, not the look. Everyone should be thankful for that). Michael, care to comment? Created attachment 8652 [details]
Replacement patch where the theme reaction code works property (including the toolbar change)
This patch is the same as the previous patch except that the code in
ColorSchemeService does the right thing (as per Stefans directives) and the
toolbar reacts to color preference changes.
Notice in the provided attachment that the problems view still wastes space to display how many problems exist. In 2.1, this would have been displayed together with the view's name. Does the theme control this labeling? Can the default 3.0 theme do better, i.e. 2.1 behavior This is more of a presentation problem than a theme problem... a property could be described on a theme to change the presentations behaviour to be "2.1 like", but it'd be up to the presentation implementor to actually honour it. Yes, the plan is to give the presentation (but not the theme) control of the status text too... but there is very little chance of this being ready for M8. Unfortunately, the view title is shown in a tab so there is no room for the status text there. The status text could be placed to the right of the tab (space permitting), but the trouble is that short status messages would look just like additional tabs. I suppose we could experiment with fonts and colours to try to make this less confusing... but my inclination would be to simply remove the marker count from the problems view and make better use of the status line (the one at the bottom of the window) when the problem view has focus. +1 to that. Every use of the title text that I've seen would make much more sense as a status line contribution of some flavour. Re: comment 7 Thanks, Kim. Kim, isn't it past your bed time <g>? The problem with using the status line is that the part has to be active in order for its status line message or status line contributions to be visible. It's a desirable feature to be able to glance at the Problems view or Search view while making changes in the editor and see its "extra info". Also, keep in mind that there are a whole whack of WSAD views (not to mention other plugins) that probably take advantage of ye olde setTitle trick and can't be expected to migrate (at least not right away). I watch professional wrestling on Thursday night. I get to stay up late and eat cookies and shout like an idiot. :) What if we migrated for them...take the text that we're scraping from the title now and just shunted it into a status line item... it doesn't solve the casual glancing problem, but I dont know if that's worth keeping the title area around. It just looks so slick without it. Would problem count always appear in the status line? If it were based on part being active, that would be frustrating because I would have to click on the view first in order to see if any problems were being filtered from it. "The status text could be placed to the right of the tab (space permitting)" -What about inside the tab if there is only one view. For stacked views, even 2.1 used an extra row of space to display status. You could also consider not having the appearance of a tabItem when there is just a single view. Being able to get the toolbar is one thing. But what about being able to hook its updating? If contributions are added to the toolbar dynamically, this would require re-layout of the view presentation. Is this possible? As a user I'd like to have certain status information be visible all the time; besides the problem count, consider the Console view. I often have more than one program running at a time and each one has output that goes to it's own page in the console view. The application name used to be in the view title bar, now it's in the title text next to the view toolbar. If you moved it to the status line then I'd have to click on the Console window to see who the output belongs to. So I think the options are: - bring back view titlebars and put the title text there, with an option to turn titlebars off for RCP applications, - put the title text in the tab name, or a shortened form of the title text (new api for shortened form?), - leave the title text next to the view toolbar (though imo it could use some sprucing up, maybe a border or gradient or something) It would be nice (and maybe you already have this) if a presentation could choose to do any of the above options it wanted, or even something different like not having tabs at all. I think the status text discussions should move elsewhere. This bug is concerning view toolbars. I just don't want the information (and Ed and Randys comments) lost if the original request is fixed. Created attachment 8722 [details] Some work in progress Regarding comment 15: you're totally right Randy, we will need the ability to monitor changes to the toolbar. I'm working on that (and something similar for the view menu) now. BTW, here's my current work in progress. This version addresses some layout issues and has a placeholder for the view menu (currently does nothing). Some things (like proper computation of the horizontal gradient) have been temporarily disabled. I've also temporarily removed the status text from the marker views to see what it looks like. Created attachment 8730 [details]
Cumulative patch for 55156, 55155, and 55437
This version is pretty much finished. The API should be complete, and the
general look and behavior is finished.
There is still a known bug: it isn't responding to theme changes correctly yet.
However, I'm posting this early version here to elicit feedback. In particular,
I want to make sure of the following:
1. The minimal view menu API I've offered is sufficient for LWP.
2. Nobody objects strongly to the increased tab size and horizontal background
gradient.
3. There are no use cases I overlooked.
Created attachment 8731 [details]
Screenshot of the java perspective with the latest patch
Created attachment 8732 [details]
Screenshot of the java perspective with the latest patch
Created attachment 8733 [details]
Screenshot of the debug perspective with the latest patch
The screenshots look good to me. It's looking closer and closer to 2.1 :). This is somewhat off topic but has anyone thought of treating editor toolbars and menus the same way as view toolbars and menus? One example - (Team) Compare with > Latest from HEAD brings up an editor that contributes three toolbar buttons to the main toolbar (ignore white space, next change, and previous change). To me it would make more sense for those three buttons to be closer to the editor, in fact just above it like views. To give Presentations a higher level of control over how contributions are presented, why not just provide access to the relevant set of contributions. IPresentablePart... public Action[] getViewMenuContributions(); public Action[] getViewActionContributions(); Correction: The APIs should not have any references to "View". This would also help satisfy the request made by Ed in comment #23. Several reasons: - Contribution managers can take different kinds of contribution items than ActionContributionItem (and adding an IAction is just a convenience for creating one of these). E.g. parts can (and do) create a ControlContributionItem subclass which creates a drop-down combobox. - There is a one-to-one relationship between the contribution managers (and their contributions) and the part, but a one-to-many relationship between a part and its presentations. JFace assumes a one-to-one relationship between a contribution manager and its controls, so the presentation cannot be responsible for creating the controls for the contribution managers (or contributions), only positioning the previously created controls. - The simple list of items does not capture their order relative to other items. (This is really only an issue for editor contributions which add to the main menu/toolbar.) To elaborate on comment 26 Although there is a one-to-many relationship between parts and their presentations, there can only ever be one presentation visible at any given time. This means that there may be the possibility of giving the presentation the ability of managing its own toolbar widgetry (possibly by destroying and recreating the widgetry or by carefully moving state between presentations). Nick and I have discussed this, but it is complicated and would need to make assumptions about the lifecycle of client contribution items (which may cause breakage). Until we can think of a safe way to expose this, we've settled for the more restrictive API you see here. Okay... committed to head. Can we try to get this fix into M8? |