resize problems show based on font size, string length (which can be longer for translated),
and monitor size and/or resolution but seeing these kind of issues even using pseudo
localized can be good indication its an actual problem
in gif, in customize panel,
the already installed near openesb line does not show fully
in first panel. the last line does not show all
parts (mbyte is not showing bottom part)
and the full msg is not shown.
in the third gif its from another time when last line
did not show very much.
Created attachment 51825 [details]
Created attachment 51826 [details]
Created attachment 51827 [details]
ignore the first gif; its not related to this.
also, as background, user should not need to manually resize.
we are not doint dynamic resizing and it is not the thing that should be done. Image than the pack/runtime name becomes
really long so that the entire string should take all the available width of the screen. I hope you agree with me that
this should not be done.. We don`t seek after satisfying all the users - it is not doable - but we work the majority of
We set the size of the panels to some pre-defined values. We calculate them and store in the file installer/engine/src/
If you want the panel to have the required size in ja/zh_CN/pt_BR locales then you should just modify this file (not
actually this but the ones that are located in translatedfiles) and increase the required sizes.
I'm going to reopen.
I do realize installers don't resize like ide.
But in past, installer team did do specific redesign and layout
of certain panels that showed resize problems; I know its a challenge
to do it since overall installer window needs to stay same size.
But translation people should not need to do changing of sizes or the figuring out of
that; and there will later be many translated versions of nb, not just the sun supported
ones, and that would complicate it even more.
My suggestion is to allocate some more space in specific panels as per the items in this or other
such issues, then I will ask if installer messages can be translated sooner rather than
later; are the installer messages final ?
like you said:
>But translation people should not need to do changing of sizes or the figuring out of that; and there will later be
many translated versions of nb, not just the sun supported ones, and that would complicate it even more.
and you said that
>suggestion is to allocate some more space in specific panels as per the items in this or other
How much space do you propose to allocate? In order to answer this quiestion you should answer the other quiestion :
what is the maximum sise for ALL of the available languages?
ALL means all. In order to get size for the panel, like you propose, you should have the translation for all the
languages before. That is not doable and not realistic.
Imagine that we do allocate some more space so that in ja/zh_CN/pt_BR translations the panels looks fine. What would
occur, e.g. in Russian translations which messages can be more lengthy that all the previous? Allocate more space again?
I don`t think it is a good idea.
Image the language where the messages are 2 times longer that in english. Should we increase the panel twice in size? I
don`t think so.
Moreover extra free space on the page doesn`t make this page look good. Agree?
I don`t mind and I don`t think that is bad to specify different panel sizes for different locales.
It is a powefull and flexible strategy. I don`t think that is not acceptable from HIE point of view (CCing Jano).
I agree that it is not the work for the translators to check the size and figure out the correct ones.
Maybe it`s the job for the developers.
It is not a problem for me to modify the file with the sizes in translatedfiles area : if it is the only problem (to
set the right size) then there is no problem at all. I`ll make the change and put the modified file into cvs.
I believe this is what we do for all dialogs and wizards in NetBeans (not 100% sure): The size of the dialog box grows with the size of content until it
reaches the edges of the screen. If the content still doesn't fit in, then scroll bars show up to make the content accessible. I'm not sure how usable it is, but
that's all we can do, I believe.
For the installer wizard we can do one of the following:
- After clicking the Next button, compute the content size of next panel and if it's bigger then the preset wizard size, then just increase the wizard size. It
will cause a "jumping" effect, but it should be easiest to implement.
- Compute the size of each panel's content in advance (before showing up the very first step) and set the wizard size accordingly.
From UI point of view the second approach is better as the jumping effect looks quite bad.
In the way that Jano is proposing the issue becomes a big, big enhancement.
Dmitry, I just guess that implementing the "jumping effect" behavior should not be that hard. It would satisfy the requirement for showing full content even
with bigger font. The user experience would not be that nice, but it's more important to see the panel content. Would it be possible to implement the jumping
effect while keeping the wizard size preset for default fonts?
Yes, implementing the "jumping effect" behavior should not be that hard. But there are several issues:
1. now the problem occurs in the welcome panel which is one of the first panels. So the question arises which size will
have the following panels? Should they have the same ("jumped")size as welcome panel or initial size? I guess it is
logically for them to have "jumped" size. In this case lets imagine that the size of welcome panel reaches the edges of
the screen(I'm talking about height now, width stay the same). User clicks next. The size of the panel stay the same but
content changes. I doubt that it will be ok for user to look at the huge panel with several lines of text on the top.
2. What to do with the License panel? There is a lot of text. Should we resize this panel as well?
May be it is better to restrict the size of the panels within some sensible values(may be different for different
locales as Dima suggested)? And if the size of the context is bigger use scrolling.
Yes, once a panel grows in size, the next panels should use it as the initial size even if their content is smaller. The big empty panels would
not look nice, but very big fonts is an extreme situation, I would say.
The license panel doesn't need to grow by itself, because the license text is inside scroll pane.
Technically, we could add the list of packs/runtime on the welcome panel into a scroll pane. That would eliminate the need for growing the
size of this panel a lot with bigger fonts. But I don't want the scroll pane border visible on that panel. So if we can use the scroll pane it's
border needs to be hidden. If we do it, than the biggest panel is the GlassFish installation we cannot do a lot about. The scroll pane would
be a solution only for extreme situation when the panel doesn't fit on the screen.
I don't think this is an rfe but actual issue that needs to be solved
for nb6.0. I did file it originally as an issue, not rfe.
I agree we can't know size for all languages, but that is one advantage
of the pseudo localization - it does use mbyte chars (which can show vertical
problems) and does have msg length longer than en (which can show horizontal
problems)so most times, if there is a problem seen with using pseudo localization,
it is a real problem.
We are about to provide to translation team the ml installers, since they need
to use them to check their work, so I will ask if they can do actual
translation of installer msgs also, at least for ja and zh and pt_BR,
so we can see if these resize situations show (or if any others exist)
Does that sound ok ?
can someone respond to my last questions below ?
(if some specific resize fixes to certain panels
itself can be done for nb6, while still keeping the same size
of the installer panels ?)
see gif for the affected panels.
We`ll resize the panels as soon as the translation would be done.
New sizes (separate set of sizes for each locale) would be stored not in installer/engine/src/data/engine.properties
but in the corresponding locale files from translatedfiles module (e.g. translatedfiles/src/installer/engine/src/data/
engine_zh_CN.properties, if I am not mistaken).
For default language (english) the resize would not be done as it is not required.
I'll try to get translations for current ja/zh/ptbr
put back to translatedfiles soon, so can give time
for installer team to customize the engine.properties files as needed.
using actual ja translations for installer, see the same
problem as reported on first panel, except not as good;
even the names of the servers are not shown at all.
correction - ja problems not on first panel but on the panel that lists
components to be installed - see the first gif.
Assigned to new owner.