Community
Participate
Working Groups
Build Identifier: 20110615-0604 Don't know how this happen but now i have wrong size of popup dialogue for hyperlink's Now i see small window only with first element I don't know how to reset size of this dialogue to default for showing possible "hyperlink variant's" Maybe this related to last OS update - Mac OS X Lion - because in my old eclipse (3.6) i see the same situation Reproducible: Always Steps to Reproduce: 1. Open eclipse 2. Open some Java class 3. Try to open "hyperlink's" popup for some type from this code editor by pressing CMD button and focusing mouse on it (needed type)
Created attachment 200659 [details] screenshot
This problem in my 3.7 and 3.6 eclipses
I found cause and solution for this problem. Cause: new mac os x lion with new general UI setting's for scrollbar's By default in mac os x lion: System Preferences -> General Option: Show scroll bars - stetted to: Automatically based on input device And with this choice eclipse show bugged size for this popup window (maybe in some other places else) But when we change this option to: Always - problem dissapear - popup opens with right sizes and show all element's correctly P.S. I think you guys can handle this workaround in code for next releases/patches.... Best Regards Bolbat Alexandr
I don't have a Mac with Lion installed. I suspect that SWT returns values for either fTable.getVerticalBar() or fTable.getVerticalBar().getSize() which don't match the rendered control. Affected code in JFace Text is in MultipleHyperlinkPresenter.LinkListInformationControl.computeSizeHint(). See also bug 352990.
The problem here is that the scrollbars are not a part of the trim anymore when the system settings is "When Scrolling". They overlay over the content view and they do not take any space. Note that this needs the fix for bug#348309. I believe Table.computeSize() and Table.computeTrim() are correct. They add the scrollbar space depending on the system setting. ScrollBar.getSize() is correct as well. It says the scrollbar is 15 pixels. The problem is that MultipleHyperlinkPresenter.LinkListInformationControl.computeSizeHint() removes the size of the scroll bar all the time from the compute size. I am not quite sure what to do. We could: 1) add API to determine that the scrollbar is not a part of the trim 2) change ScrollBar.getSize() to return 0 even though the size is not really zero which seems unsafe.
There is also a third option: 3) Always include the scroll bars in computeSize() and computeTrim().
> 1) add API to determine that the scrollbar is not a part of the trim This would mean that all clients which got broken have to change their code.
The LinkListInformationControl's way of dealing with scrollbars is quite special. I guess it's OK that we have to adapt this code to support the new behavior. > 1) add API to determine that the scrollbar is not a part of the trim This should already be available through ScrollBar#getThumbTrackBounds(). > 2) change ScrollBar.getSize() to return 0 even though the size is not really > zero which seems unsafe. I agree this sounds wrong. > 3) Always include the scroll bars in computeSize() and computeTrim(). I guess that would cause collateral damage in other places.
(In reply to comment #8) > The LinkListInformationControl's way of dealing with scrollbars is quite > special. I guess it's OK that we have to adapt this code to support the new > behavior. I guess we could live with that but should mention it in the migration guide.
*** Bug 354691 has been marked as a duplicate of this bug. ***
Note this bug also affects the Quick Editor Switcher popup. Screenshot attached to bug 354691.
(In reply to comment #11) > Note this bug also affects the Quick Editor Switcher popup. Screenshot attached > to bug 354691. Depends on the fix. The switcher uses SWT's org.eclipse.swt.custom.TableEditor.
> > 1) add API to determine that the scrollbar is not a part of the trim > This should already be available through ScrollBar#getThumbTrackBounds(). Hmm, this is getting ugly. At the time when we compute the sizes, the Table has size {0, 0} and thus getThumbTrackBounds() also doesn't return anything of interest. If SWT could add an explicit API like ScrollBar#isOverlay(), that would be great and it would also make other similar fixes easier to implement.
The Quick Editor Switcher popup (bug 354691) computes the size in AbstractTableInformationControl#inputChanged(Object, Object). tableSize.y - viewerTable.getItemHeight() - viewerTable.getItemHeight() / 2 is bogus, but even after replacing this with something like viewerTable.getHorizontalBar().getSize().y , we still need to know whether the scrollbars are overlays or not.
I believe the safest fix at this point is: 3) Always include the scroll bars in computeSize() and computeTrim(). given that we would not be able to add API in the 3.7 branch. Fixed in 3.8 branch. Felipe, please review for 3.7.1. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0299941c68a463c97176c9da97b333292c2da0fb
Previous fix did not take into consideration the scrollbars style bits. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/bundles/org.eclipse.swt/Eclipse%20SWT/cocoa/org/eclipse/swt/widgets/Scrollable.java?id=35d457460fd1a9087e8ef21709ae071073770ebb
Fixed in 3.7.1 branch as well.
> 3) Always include the scroll bars in computeSize() and computeTrim(). > > given that we would not be able to add API in the 3.7 branch. This is not given, but needs PMC approval.
With the last change, the textWidget.computeTrim(0, 0, 0, 0) in SourceViewer.RulerLayout#layout() now returns a fake trim with width and height of 15. This is too big. The legacy scrollbars have size 15, but the overlay scrollbars are only 10 pixels.
The overlay scrollbars seem smaller to me as well, but I still get 15 pixels if I call: [NSScroller scrollerWidthForControlSize: NSRegularControlSize scrollerStyle: NSScrollerStyleOverlay]
*** Bug 357427 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > With the last change, the textWidget.computeTrim(0, 0, 0, 0) in > SourceViewer.RulerLayout#layout() now returns a fake trim with width and height > of 15. This is too big. The legacy scrollbars have size 15, but the overlay > scrollbars are only 10 pixels. Are we happy with the current solution?
(In reply to comment #22) > Are we happy with the current solution? Yes. I don't see any negative effects of this in the UI. The only remaining real issue is bug 355683. I mentioned the wrong size in that bug as well, so maybe it can be fixed there. Or it just stays until somebody has a real problem with it.
*** Bug 357760 has been marked as a duplicate of this bug. ***
