Community
Participate
Working Groups
This is a bug for a specific work item described in bug 59850. The R2.1 style presentation needs a title bar in the views.
I can look at this one but I need a little guidance - who should be creating the ViewForm and where should it appear in the widget hierarchy? Should there be a separate one for each tab?
I started looking at this one on friday afternoon. Nothing works yet, but I'll find the code and post it as (a starting point) sometime this afternoon.
No problem, but could you indicate which ones you and Michael are *not* looking at in the next, say, 7 days? Or the ones you *might be* looking at, either way.
I looked into my history for this. Turns out the only relevant code was to copy the old ViewForm to the plugin (that was already submitted). The rest was talking to stefan to figure out where to start. Rather than me passing on what he said...he'll post some "getting started" tips directly. As for who is doing what, the assigned fields have been updated. We'll make sure to take ownership of the one's in active development. Bugs assigned to Platform-UI-Inbox will be up for grabs.
Random bits of advice off the top of my head: 1. You could use the old ViewForm, but I suspect that the new one will also work well enough. (You may want to use the old CTabFolder, though.) 2. The old view titles used CLabels. Use ViewForm.setTopLeft to make them show up in the right spot. 3. You'd probably be best off using one ViewForm for the entire stack, rather than using one per tab. 4. Similarly, use one CLabel for the title and just change its text depending on which tab is active. You can also share one view menu button for all the tabs (just hide it and remove it from the ViewForm when it is not needed). The tricky bit is the toolbar and the actual view widgetry. You don't get to create either of those, so you can't choose their parent. Drop invisible composites into the ViewForm so you can determine where they should be. Then, whenever you need to resize the presentation, convert the bounds of your invisible composite into display coordinates and use this to reposition the toolbar. The computeSize method of your toolbar's invisible composite will need to return the same thing as the computeSize method of the toolbar. I do this by attaching a simple layout to the composite (check out ProxyControl). The widget hierarchy should look like this: WorkbenchPage composite { View toolbar View control CTabFolder* (the tabs) { ViewForm* { CLabel* (view title - setTopLeft) Toolbar* (view dropdown - setTopRight) Composite* (invisible - placeholder for current view's toolbar setTopCenter) Composite* (invisible - placeholder for current view's client area) } } } * - indicates a control you will create yourself The new look presentation also has a toolbar placeholder in the CTabFolder, since the toolbar is allowed to move beside the tabs (you won't need this). Some useful examples from the new look presentation: - PartStack -- behaves like a custom widget. It creates the CTabFolder and the ViewForm and handles all the fiddling about with proxy composites. - ProxyControl -- used for all the invisible placeholder composites - BasicStackPresentation -- handles the higher-level aspects of the presentation
Andrew, are you still planning on sending some (maybe broken doesn't matter) code for this as you indicated in #2?
I didn't find anything that was useful beyond what is already in the project (which is just a copy-and-paste of the 2.1 ViewForm). When I posted comment 4 I thought I remembered having something appearing for the title bar, but now that doesn't seem to be the case -- perhaps it was in a dream :-) In any case, I think that Stefan's comment 5 has more detail than I remember discussing with him anyhow.
Correction to comment 5: "PaneStack" should have been "PaneFolder"
I've committed code for the view title bar. Give it a try. Most things work correctly. Known issues: - tab bounds are off a couple pixels if the tabs are at the bottom - tabs are not suppressed if there is only one tab - tear-off doesn't work (you get a blank window) - if you change the preference option to put tabs at the top or bottom, the views don't refresh correctly - if the controls don't all fit on the title bar it should draw a horizontal line separating the title bar and the controls area - uses hardwired R21 colors - there's a refactoring opportunity with duplicate code in R21EditorStackPresentation and R21BasicStackPresentation - if bug 55458 is fixed, code can be simplified a little One unintentional enhancement snuck in - you can drag the entire view stack by dragging the title bar. I think we should leave it.
Ed, I've added API for the third state and deprecated IStackPresentation.isMoveable(...) and StackPresentation.setActive(boolean). Please make the appropriate changes to your presentation.
What's the replacement for isMoveable(), and what about isClosable()?
I'd like to mark bug 59952 as fixed since the only problem I can see there is drawing minimized views, which is likely related to the first bullet in comment 9. Lets just add that problem to this bug: - minimized views drawn incorrectly Ed, do you think we should open a few new bugs for these problems or just track them in here for now?
I suggest splitting these into their own bugs: - R21 colors and themeing (currently uses hardwired R21 colors; R3 enhancement) - Tear-off support (R3 enhancement) - Support minimized views (currently minimized views are drawn incorrectly; R3 enhancement) - Support immediate tab position change in views and editors (if you change the preference option to put tabs at the top or bottom, the views don't refresh correctly; R3 enhancement) Just for organizational purposes, the toolbar separator should probably go into bug 59950 or bug 59952 (your choice). That leaves these issues in this bug entry before it can be closed. These are all regressions from 2.1: - Suppress tabs if there is only one tab - Tab bounds are off a couple pixels if the tabs are at the bottom - Support third stack presentation state in setActive() Sound ok?
I think that is a good breakdown, I'll open new bugs for those issues this afternoon. Also, it looks like 2.1 view title bars have a white outline, while the ones r21pres do not. Finally, kim is working on using the API provided by stefan in the 3.0 presentation code. When she's finished we'll be able to use that code as a sample.
These are fixed in HEAD: - Support immediate tab position change in views and editors (I'll close that other bug) - Tab bounds are off a couple pixels if the tabs are at the bottom - 2.1 view title bars have a white outline, while the ones r21pres do not.
Re: comment 11 isMoveable(...) has been replaced by isPartMoveable(...) and isStackMovable(...) FYI, this change was part of a pass to remove methods that do something special when given null as one of their arguments.
I had an idea about merging the presentation of view title bars - see bug 58150.
Other that making some decisions on the appearance of minimized views (bug 60955) are there any remaining view title bar issues?
No I think it's done
Ok, then lets track the minimize decisions in its own bug 60955).
