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.

Bug 34104 - I18N - Some parts of options window do not fully appear in other locales when translated and/or using larger font sizes
Summary: I18N - Some parts of options window do not fully appear in other locales when...
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: _ tboudreau
URL:
Keywords: I18N
Depends on:
Blocks: 33246
  Show dependency tree
 
Reported: 2003-06-02 21:05 UTC by Ken Frank
Modified: 2008-12-23 12:55 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
gif of options window (23.26 KB, image/gif)
2003-06-02 21:07 UTC, Ken Frank 		Details
Diff, unlovely but works (2.58 KB, patch)
2003-06-11 01:32 UTC, _ tboudreau 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2003-06-02 21:05:10 UTC 
Using pseudo localized product, with each message
or label
having additional multibyte text, and using
-fontsize 16
option, running in Chinese locale,
many of the labels of key values in right
side of options window, as per image attached,
don't show fully and require user to use the
vertical resize controls to see all label.

The values part of this section it could be
expected that user might need to use controls
to resize since those values could be of varying
length as provided by user or others, since this
part is not an informative label.
Chinese localization will use a larger font than
default
one now used so these issues will be more visible
to them,
but this can also be viewed as a general or a11y
issue
since may be visible to users in english locale
who use
larger fonts.

Assumption is that user should be able to see
all items in a given window when it appears and
should
not need to resize it to see those things.

That is, the UI area or window should dynamically
resize
itself to show the needed contents.
(this does not apply to contents of textfields,
areas
controlled by scrollbars)

To emulate in non multibyte locale without
multibyte
in messages or longer messages, you may need to
run
with fontsize 18 or 20 to see what we are seeing
with
fontsize 16. Even with larger sizes, it may not be
seen
exactly the same due to the effect of multibyte
and longer
strings.

This issue is marked with the FONTSIZE keywork;
bugs so
marked will not appear on quality dashboards and
will not
need to be waived or fixed for English FCS
products of this
release.

For Netbeans issues, this will be marked as
blocking 33246.
Comment 1 Ken Frank 2003-06-02 21:07:15 UTC 
Created attachment 10562 [details]
gif of options window
Comment 2 mslama 2003-06-03 10:22:47 UTC 
Assigning to Dafe
Comment 3 David Simonek 2003-06-10 14:16:08 UTC 
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.
Comment 4 Ken Frank 2003-06-10 16:23:22 UTC 
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
Comment 5 _ tboudreau 2003-06-10 22:07:24 UTC 
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.
Comment 6 _ tboudreau 2003-06-11 01:31:44 UTC 
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
Comment 7 _ tboudreau 2003-06-11 01:32:48 UTC 
Created attachment 10645 [details]
Diff, unlovely but works
Comment 8 David Simonek 2003-06-13 14:26:10 UTC 
Reviewed, but not entirely OK - I would use
Utilities.getUsableScreenSize instead!
Comment 9 _ tboudreau 2003-06-17 01:07:53 UTC 
Merged to release35 branch.
Comment 10 Ken Frank 2003-07-21 21:34:35 UTC 
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.
Comment 11 Lukas Hasik 2004-04-02 16:26:43 UTC 
v