Community
Participate
Working Groups
I20100804-0100 1. (broken since at least 3.6) Out of the box, the Errors/Warnings preference page should come up without horizontal scroll bars (no matter what sections are expanded initially). 2. With the filtering, the vertical scroll bar appears and disappears more often, which looks noisy. We should try to show the vertical scroll bar all the time, but still keep the horizontal bar appearing dynamically if necessary.
Created attachment 176104 [details] patch to always show vertical scrollbar (In reply to comment #0) > I20100804-0100 > > 1. (broken since at least 3.6) Out of the box, the Errors/Warnings preference > page should come up without horizontal scroll bars (no matter what sections are > expanded initially). This got introduced in 3.6 when the label for the checkbox at the bottom changed from 'Treat errors like fatal compiler errors (make compiled code not executable)' to 'Treat *optional* errors like fatal compiler errors (make compiled code not executable)' I tried to use SWT.WRAP, but that does not work for buttons (Bug 13802). We can either reduce the length of the label, or put the text in brackets on the next line, or make the dialog a bit wider - some of our preference pages are wider e.g Code Style > Clean up , Editor > Content Assist. > 2. With the filtering, the vertical scroll bar appears and disappears more > often, which looks noisy. We should try to show the vertical scroll bar all the > time, but still keep the horizontal bar appearing dynamically if necessary. Patch attached
Makes it less noisy. Discussed the initial scroll bar issue with Markus: - we want to keep the length of the preference (except of a small wording change I just committed to HEAD - you need to debug why the horizontal scroll bar appears: there are two scenarios: 1) broken (scroll bar) if you navigate to the page from another page 2) works (no scroll bar) if the dialog opens directly on the that page
Created attachment 176143 [details] screenshot > - you need to debug why the horizontal scroll bar appears: there are two > scenarios: > 1) broken (scroll bar) if you navigate to the page from another page > 2) works (no scroll bar) if the dialog opens directly on the that page See the attached screenshot of the two cases. It works because the dialog is just wider :) (though I havent debugged why it is wider when you open it directly, and narrower when you navigate to the page from another page)
>though I havent debugged why it is wider Well, that's the whole point ;-) Our page can specify its desired with and that should work (be applied) in both cases.
Created attachment 176161 [details] fix This patch fixes the problem. The cause of problem was fix for Bug 294763, we only need to set a small height to avoid 2 scroll bars. The width can be computed based on the content.
(In reply to comment #5) > Created an attachment (id=176161) [details] [diff] > fix Fixed in HEAD.
For my education: why did it work in one but not the other case?
(In reply to comment #5) > Created an attachment (id=176161) [details] [diff] > fix Deepak, please leave some explanation in the ProblemSeveritiesPreferencePage that tells why we set size.y= 10. A note in bug 294763 would also be nice, so that others know that there's a better solution. In the FilteredPreferenceTree, please use a ControlAdapter instead of a ControlListener with an empty method.
(In reply to comment #7) > For my education: why did it work in one but not the other case? Look at org.eclipse.jface.preference.PreferenceDialog.showPage(IPreferenceNode) line 1292 (if (oldPage != null) ) - there are 2 cases depending on whether there was a previous page or not. If there was a previous page then size of content of new page is compared with the current dialog size. If content is smaller than no action is taken. (In reply to comment #8) > (In reply to comment #5) > > Created an attachment (id=176161) [details] [diff] [details] [diff] > > fix > > Deepak, please leave some explanation in the ProblemSeveritiesPreferencePage > that tells why we set size.y= 10. A note in bug 294763 would also be nice, so > that others know that there's a better solution. > > In the FilteredPreferenceTree, please use a ControlAdapter instead of a > ControlListener with an empty method. Done
