This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | I18N - Some parts of options window do not fully appear in other locales when translated and/or using larger font sizes | ||
---|---|---|---|
Product: | platform | Reporter: | Ken Frank <kfrank> |
Component: | Window System | Assignee: | _ tboudreau <tboudreau> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | dpavlica, jf4jbug, tboudreau |
Priority: | P2 | Keywords: | I18N |
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 33246 | ||
Attachments: |
gif of options window
Diff, unlovely but works |
Description
Ken Frank
2003-06-02 21:05:10 UTC
Created attachment 10562 [details]
gif of options window
Assigning to Dafe Ken, is the issue that property sheet window in SDI is too thin by default? Which kind of property sheet window - generic one which is opened using View/Properties or specific one opened using right click popup menu/properties? I assume that in MDI the problem exists as well? For generic property sheet we have implementation problem here - it's *impossible* to assure that all long chinese texts of properties will be visible, as width of property sheet is not dynamic (and shouldn't be) and prop sheet can't know length of all properties in the system. "Hopefully good enough" solution would be to define modified window layout for chinese localization, giving property sheet and explorer slightly bigger space, with the drawback that smaller space remains for editor. For specific property windows, it should be hopefully easy to provide correct initial size. Tim, could you take this issue? Thanks. David, I'll definitely defer to Tim on this one as I'm still getting clear on the different types of property windows. From my understaning, all or most property sheet will be rewritten soon but not for nevada ml, so that I don't know if any of these issues should be fixed for nevada ml; again Tim can tell you more. And I agree with you that it is impossible to know length of all properties; but what about the key on left side vs the value on right side -- is the key itself known so that sheet could dynanically resize ? So I think for testing we will assume that no fixes might be in property sheets of any kind for nevada/nb ml. And we will tell QA who is testing about this so they don't think issue is not fixed. Tim, am I getting this right ? Ken I've got a patch which does the following: - Returns an increased value from getPreferredSize() if the font size is larger (limited by screen size) - Sets the splitter position to a location more leftward Works with both the old and new property sheet. In the process, I replaced the old SplittedPanel with a JSplitPane in the dialog. There remains the question of whether there are any QA tests that expect a SplittedPanel and will break - I'll either prove that to my satisfaction and commit it or attach a patch and ask QA to test it. Committed to trunk, Checking in OptionsAction.java; /cvs/core/src/org/netbeans/core/actions/OptionsAction.java,v <-- OptionsAction.java new revision: 1.52; previous revision: 1.51 Created attachment 10645 [details]
Diff, unlovely but works
Reviewed, but not entirely OK - I would use Utilities.getUsableScreenSize instead! Merged to release35 branch. I'm not sure I know how to verify this one without waiting for new properties window implementation (or if it makes sense to verify it until then) Also then there is meta issue of if window resizes such that its at max width of screen, should window wrap or have scrollbar or just be as is ? There are some fontsize issues that have been fixed where we still see this behavior, and wonder if there should be some global task about it and where that might be filed if so. v |