Community
Participate
Working Groups
I20051220-0800 The PageBookView's toolbar doesn't properly re-layout when another page is activated. The toolbar retains the old bounds and does not show additional items. Steps: - open Console view - open page "Java Stack Trace Console" (from the rightmost toolbar button) - resize the Console view such that the toolbar jumps to the second row (see attached screenshots) - switch to page "CVS" -> toolbar misses rightmost items; they only appear when the view is resized The same happens in the Search view when switching from a text search result to a java search result page.
Created attachment 34068 [details] Screenshot Oops, I forgot to attach the screenshots. I just saw the same problem in the Outline when switching from a plugin.xml source editor to a Java Editor and vice versa. Apparently, this should already have been fixed once in bug 64866, but I still see it in the 3.2 builds. Bug 63057 is another dup of this problem.
Could this bug please be considered for 3.2? It is rather annoying and makes e.g. the Search view hard to use when it is in a view stack with many other views. The screenshots show how the bug create blank space in the toolbar. If you reverse the sequence of pages shown, it is even worse: The toolbar becomes too narrow and therefore makes the rightmost buttons (e.g. the history menu button) invisible. The user has to know about this bug in order to get back the hidden buttons and the ability to switch to other pages again.
So I am hoping to look at this for 3.2, just not 3.2M5. There should be some presentation work in 3.2M6. PW
I am seeing this as well. It especially happens for me in the synchronize view.
Paul, I would really like to see this bug fixed for 3.2. It drives me nuts since in my view layout the important toolbar button "Show Change Sets" in the Sync view is always clipped and there is no visual indication that the button exists at all.
Created attachment 36106 [details] Screen shot showing the sync view
See also bug 128888.
I would really appreciate if you could set a target milestone to this bug to make sure it doesn't slip into 3.2.
eric were you looking at this? do you have a target milestone?
I have it ... I'll be picking bugs for RC1 next week. PW
Paul, did you really wan't to tag this RC4?
Yes PW
I think the point is that at this stage we should not 'plan' to fix anything in RC4. RC4 will be locked down and we will only be fixing things that are critical and that the PMC etc... agrees should be fixed.
Please update the 3.2 polish list if you don't plan to do this for 3.2.
polish wiki is here, Paul please stop by if you want to do this together http://wiki.eclipse.org/index.php/Polish3.2
Also see bug 100423 and bug 93878 PW
Mvm, would you like to try this one?
similar to bug 55295 ?
> similar to bug 55295 ? No, there it is OK that toolbar buttons disappear (the empty outline page has no buttons). Bug 55295 is only about showing an (enabled) view menu button that does nothing when you click on it. That bug is also permanent (i.e. resizing the view doesn't help). This bug is about what you can see in the attached screenshots: clipped and wrongly positioned toolbars after switching pages in a PageBookView.
I can confirm this problem with Eclipse 3.2 release.
Moving to Paul. MVM, I think this was the last bug you owned!
*** Bug 100423 has been marked as a duplicate of this bug. ***
Please finally fix this bug for 3.3. It makes us look really stupid.
There's no resources for presentation work in 3.3 ... it's unlikely bugs like this and bug 128455 will get fixed. PW
I'm maxed out with the menu contribution work in 3.3M6. I hope to get a chance to look at this for RC1, but there's a chance it could slide again. If someone wants to provide a patch I'll be happy to look at it. PW
Paul, I'll take this off of your hands...
Markus, I've been trying to repro this with no success (failure?...;-). I've tried using both the buttons (left one toggles between them and the right one makes you select the pagebook you want...). Note that both the CVS and Stacktrace books have identically sized TB's now... I've also tried the Synchronize case (i.e. one Compare to another branch and one actual CVS Synchronize). Here the size of the TB's is greatly different but I still can't induce the issue. What am I doing wrong ?
It's easiest to reproduce in the Search view: - new workspace (with I20070327-0800) - paste this into the Package Explorer: public class MyType {} - select MyType in the editor - press Ctrl+G (Search > Declarations > Workspace) - make the Search view so narrow that the toolbar just has to jump below the view description (clipped view description is bug 93878) - press F12 to focus editor - press Ctrl+Shift+U, I (Search > Occurrences in File > Identifier) - switch back to the other search result => Last few tool items are not reachable any more. No way to switch to the other search result unless you know that resizing the view fixes the layout problem.
Got it..the trick seems to be to make it small enough to go -below the description- (i.e. not just on to the second line...). Now I should at least know where to look...
*** Bug 128455 has been marked as a duplicate of this bug. ***
(In reply to comment #27): there is already an automated JUnit test which fails because of presence of this bug, see comment 36 bug 128455.
I just realized that this is not only a problem when switching pages, but more generally when view toolbar contents change. To reproduce, you can also do a Java reference search and then toggle Search view's view menu > Show as List/Tree. The code that updates the toolbar is in org.eclipse.search.ui.text.AbstractTextSearchViewPage.createViewer(Composite, int).
Hi, FYI I'm seeing what was reported in bug 128455 on OS X as well (marked as a duplicate of this bug).
Thanks for the info Markus; there's a clear breakage somewhere along the 'update' -> 'layout dirty' mechanism. The most suspcious code so far is that these menus seem to use 'SubMenuManagers' (and most others don't).
Committed in >20070425. PaneFolder's 'layout' method was over-optimized in that it did -nothing- if the old and new toolbars were both not in the upper area... Markus, if you know of other scenarios related to this could you try them out? Everything I tried seems to work ok and the old code was obviously incorrect but I'd like to ensure that I've covered all the bases... Sorry but I didn't have time to look into the 'title' wrapping issue...
Verified in I20070430-0800. The toolbar update flickers a bit, but that's negligible compared to the deliverance of working PageBookViews ;-) Thanks a lot for fixing this!
*** Bug 186675 has been marked as a duplicate of this bug. ***
*** Bug 135273 has been marked as a duplicate of this bug. ***
Note: this fix has been moved to the default presentation as part of the work in Bug 180732[Presentations] R33 presentation classes: do we still need?
Sorry Kevin, I missed th context of your statement. What are you asking if we still need?
(In reply to comment #40) > Sorry Kevin, I missed th context of your statement. What are you asking if we > still need? The "do we still need?" is part of the title for the referenced bug :) I was just commenting that the fix you had made for this bug was made in the R33 presentation package. That package has been nuked as part of Bug #180732. Now the default presentation package is the defacto R33 presentation. The fix you made was thus migrated to the default presentation package. Hope that makes more sense.
Yup, and thanks for removing the stale package...it was confusing at best...
