Created attachment 10354 [details]
main window menu bar

Assigning to Dafe.

Ken, after 5 min of guessing what this issue is about, I see now that
initial width of main window is too small for chinese localization and
menu text is stripped off.
Is that right?

If so, behaviour of my proposed fix is to make initial width fit
chinese menu texts, up to screen width limit. On second and further
starts, width of main window is remembered from previous sessions.

Could I ask you to be more specific and straight in future in
description of what is wrong? I have hard times to understand as I
don't understand chinese language and localization at all, picture
attachments helped a bit, but not enough unfortunately, explanation
sentence would be valuable, thanks.

David,

Yes, let me clarify issue some more.
This is really not just i18n issue but potentially
can be seen by user in english running with larger
fonts, so could be a11y issue also.

The gif shows that, when larger fonts are used
and that each label of the main window would be translated,
that each menu label seems to only be a fixed
width and thus does not show completely.

I think if the fix just allows dynamic resizing
of window, as you mention, up to screen width,
that seems to be best kind of fix.

You mention about window width being remembered -
is that an existing feature of ide or is that new one,
and does it apply just to main window or to others ?

Ken
ken.frank@sun.com

Yes, remembering the window positions is already existing, independent
feature and shouldn't be modified.

Ahha, perhaps now I understand the problem more and I'm starting to
think that we can't do anyhting here, it's not a bug.
I'll try to explain: There is UI feature (relatively strong) that all
main window should restore to the size which user chose in last
session. So that it mustn't resize to new size, even if fonts were
changed.

The only case when main window should auto-resize is very first start,
and this is exactly how it works now AFAIK.

Jano, what is UI position in this issue? Forget about user window size
settings when main menu don't fit or not?

I would recommend to leave things as they are, because auto resize of
main window could be potentially very annoying feature (also according
to several UI books).

When we tested, we used fresh userdir and
the image in gif is how window came up
the first time, so would this be issue
for this case ?

Also, are there any other windows in ide
which remember their size - this will be
helpful information for testing.

ken.frank@sun.com

Dafe, is it possible to do this:
Try to set the main window width for the first time as we do it now
(AFAIR, 70% of screen width, not sure). If the menu bar doesn't fit
the width, then set the window width so that the menu bar fits (up to
the screen size).

In other words, the main window first time width = max("70% of window
width", "menubar width"), but not larger than the screen width. :-)

Each following start up uses stored values (user customization).

To Ken: Yes, you are right, this case is valid bug and should be
fixed, as Jano proposed (I agree with his proposal completely). Other
windows - all user customized window dimensions and constraints should
be kept between sessions. If they are not, then it's a bug probably
(yes we had several bugs concerning this).

To Jano: OK, agreed.

Update: I won't be able to fix this bug in given time constraints, fix
is tricky and probably ugly, as whole main window sizing strategy
doesn't count with fontsize at all.

- sizing code knows nothing about main window menu bar (and can't
know, as main window isn't constructed yet)
- information whether it's very first start is needed - I don't know
how to obtain such info.

marking as WONTFIX.

Oops. Not WONTFIX, sorry, reverting back.
Further examination is needed and probably overall change of main
window sizing strategy is needed. Means bigger task, probably time
consuming.

Created attachment 10730 [details]
s1s5 main window on Windows

Created attachment 10731 [details]
s1s5 on solaris

I got the issue from Ken. Ken raised a very important issue.
But the case is not so bad, because most Chinese messages are shorter
than English, so the component size doesn't increase much when 14px
size is applied. I attached two snapshots from nevada (final
translation message).

I don't know how many GUI components' size should be modified, for I
haven't started Chinese version testing. What I am doing is just to
verify the font size modification in Chinese version. So far, I
haven't found any overlapping or message trunc. The case can be found
in later testing. I will keep you update.

Does the GUI size depend on monitor's resolution? What is the minical
requirement?

Glad to hear and see that this issue has smaller impact then we
thought, we can waive more easily now.

To your question - yes, initial size of main window is dependent on
monitor resolution. Unfortunately I don't know what's the minimum
supported resolution size, but I'd say we should fit into 1024x768
pixels (for English localization it's OK). Jano should know more, Jano?

You should test it on 1024x768 screen resolution. It is small enough
because the main window is open smaller by default only if the screen
resolution is smaller (e.g. 800x600) and we can not do nothing in such
case.

Planned to be probably fixed for 3.6.

News: I found solution suggested by HIE (Jano) hardly implementable,
leading to fragile, unmaintainable code.

Thanks to Peter Z., I tried another approach and it works much better:
The trick is to provide own branding for localized versions of
Netbeans, where main menu is longer. I'm attaching jar file, which
contains example branding for cs locale. Copy it to the lib directory
and start Netbeans with clean userdir and -locale cs and you will see
that Main window now occupies 98% of screen width, instead of 80% as
for regular english build.
So here are the instructions to fix on your side:
- provide branding for your locale as shown in attached jar
- adjust numbers of "relative-width" parameter in windowmanager.wsmgr
xml file (value 0.98 means 98% of screen width) so that your menu fits
nicely also with 1024x768 resolution, if possible.
-----
I hope my explanation is clear, please ask if something is not clear.

Created attachment 13072 [details]
jar file containing example branding

Here is link to branding documentation:
http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/doc-files/i18n-branding.html

I wanted to clarify about proposed solution of having branded
file for localization that had customized dimensions in it -

From i18n view, this does not seem like correct approach as l10n
should not need to do this - usual i18n solutions is to have main
code do the right thing as much as possible about the sizing.

As far as I know, there is no other place in ide where l10n needs
to customize dimensions and IMO does not seem like the way to go.

Also, this is also a general or a11y issue as user of en product
can use -fontsize option to run and will see same issue, and the
customized file solution is not available anyway in this case.


ken.frank@sun.com
01/26/2004

OK, that means IMHO that we should left things as they are, unchanged.

Let me summarize the issue:
- user impact of this issue is small to none, issue is not visible in
standard distributions, even in Chinese (see jkang's comment).
- issue is visible in reality only when user is running on
sufficiently small resolution (1024x768) and sets big fonts. Then
there can be a situation where some main menu items will not be fully
visible (such situations will arise anyway! when using sbig fonts)
- problem exists only during very first start of the system, during
every other start system has to respect user choice and not change
size of main window, even if menus are cut.
- branding solution is not comfortable one from i18n point of view
- programmatic solution is not possible without ugly hacks that are
likely to be broken in future
- no programmatic solution can solve the problem 100% either, if user
sets too big fonts, problem arises again.

Given all that, I suggest to not do anything with this issue.

xx

Changing resolution to wontfix to better refrect situation.

verified