Bugzilla – Full Text Bug Listing
| Summary: | CTabFolder rendering problems | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Boris Bokowski <bokowski> | ||||||||||||||||||||||
| Component: | UI | Assignee: | Bogdan Gheorghe <gheorghe> | ||||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||||
| Priority: | P3 | CC: | emoffatt, gheorghe, pwebster, remy.suen, susan | ||||||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||||||
| Target Milestone: | 1.0 RC2 | ||||||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||||||
| OS: | All | ||||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||
|
Description
Boris Bokowski
Created attachment 173124 [details]
screenshot for problem 1 and 2
Created attachment 173125 [details]
screenshot for problem 3
(In reply to comment #2) > Created an attachment (id=173125) [details] > screenshot for problem 3 There is bug 315086 for this. I see it once in a while. see also bug 314159 and bug 281771. It seems to me that we are wrestling with two separate issues: - the toolbar is not moving downward (bug 281771) so in some view stacks, you rarely have enough room for a tab. - the shrinking tab algorithm needs work - (dangling stuff, missing tabs, etc.) If we can address the first issue then the second one isn't hit so often. I talked to Bogdan about this. He's looking into some possible resize listener hacks that could help. Barring that, I could investigate some changes in the renderer to get the toolbar moved down? I completely understand Eric's point in bug 281771 that getting 3.6 behavior is risky at this point, but I'm wondering if there is some more surgical hack to force the toolbar down that we could try (in fact, having the view toolbar always appear below the tabs would be a better solution in my opinion than having the current behavior.) (In reply to comment #4) > (in fact, having > the view toolbar always appear below the tabs would be a better solution in my > opinion than having the current behavior.) I agree. Maybe this is what we should try to implement first? Created attachment 174411 [details]
Patch
Created attachment 174429 [details]
More changes to above patch
Second part of patch
Created attachment 174444 [details]
Safe up the get/set TopRight code
The current 4.0 implementation shares the same TB amongst different CTF's. This means that it can arbitrarily reparent the topRightControl, leaving a topRightComposite that no longer has any children.
Committed in >20100715. Applied the patch. Created attachment 174508 [details]
screenshot with white toolbar
Bogdan, on Cocoa the new code sometimes produces white background in the toolbar.
Created attachment 174509 [details]
screenshot with white composite next to tabs
Perhaps the same problem as the previous screenshot, but the white stays even if the toolbar moves down.
Created attachment 174521 [details]
Take 3
Tried another approach that is cleaner...
Fixed in HEAD > 20100716 Created attachment 174533 [details]
Add/remove the resize listener
Created attachment 174534 [details]
Add/remove the resize listener - safer
Committed in >20100716. Applied the patch. we can use bug 314159 to track the remaining issue - where a close box or chevron can dangle outside the tab. (The 3.6 approach is prevent the part from getting that thin)... *** Bug 315086 has been marked as a duplicate of this bug. *** |