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.
running in ja locale, using pseudo localized, and at 14 point font (which is only 3 pt larger than default 11 pt font, part of the Application view of the project properties (Descriptoin area) does not show this area when invoked. user should not need to manually resize to see any part of a window or dialog. see attached gifs of as invoked and then after manual resize.
Created attachment 41129 [details] image
Created attachment 41130 [details] image
other resize situations for properties window - see new gifs also 1. run section the configration dropdown does not show all parts - according to xdesign and usability, dropdowns do need to do this 2. web start section the dropdown for codebase section does not show all of its contents
Created attachment 44694 [details] image
Created attachment 44695 [details] image
*** Issue 110974 has been marked as a duplicate of this issue. ***
Should be fixed with issue #64780.
this part is not fixed from report and last 2 gifs: 1. run section the configration dropdown does not show all parts - according to xdesign and usability, dropdowns do need to do this 2. web start section the dropdown for codebase section does not show all of its contents ken.frank@sun.com
. run section the configration dropdown does not show all parts - according to xdesign and usability, dropdowns do need to do this seems to be only part thats not ok now. ken.frank@sun.com
can this be fixed for 6.1 ? ken.frank@sun.com
Milane? BTW I don't see any problem.
using recent 6.1, I still see the problem in run section as described and also in the dropdown for the web start section, as described. its true resize problems show with some combination of larger font size and length of translated string, and can vary per platform. but in past, most if not all resize problems reported have been real in that something was hardcoded or layout mgr api was not used correctly to avoid these situations. ken.frank@sun.com
the strange thing is, for the run section, if pick the customize option from the ide window itself, on the toolbar, where the dropdown is, the props window does show ok; no resizing problems vs the problems seen when invoking project props from project menu. ken.frank@sun.com
kfrank, there were some fixes in this area, please could you check latest build and attach new screenshots in case the problem persists. Thanks.
I don't see anything that has changed and the 3 gifs attached, first, 3rd and fourth, show the problem as before. as mentioned, this is the props when choosing the project in explorer menu. when choosing the customize choice on the toolbar, that props window is ok even though it seems to be the same subwindows in it. Are these actually 2 windows - the props from choosing from explorer vs props from choosing customize ? if so then can see how one might be hardcoded or not fully dynamically resize. or if same, is there some sizing info of them communicated at time of the choice that would be different if invoked from explorer vs from toolbar ? ken.frank@sun.com
moving opened issues from TM <= 6.1 to TM=Dev
my original filing mistake - was filed at wrong priority - should be p2 like all other such resize. since it still appears in 6.1 will change release to that one also. or let me know if a new issue with all details here is needed for 6.1. ken.frank@sun.com
Milane?
Honzo? This issue will be resolved for 6.5 release.
Ken, are there any guidelines on how to create such a build to verify if the fix works? It can be only reproduced on the special build, so I don't have a way to reproduce/verify the issue. Thanks.
Ken?
send me the jar(s) that have the fix; I will pseudo localize and return to you so you can run in other locale using 14 pt font. you could just take your own bundles and add extra characters the msgs, though am not sure if not having mbyte in them would not cause the problems. ken.frank@sun.com
I'm sorry, but it works for me, I don't see any single dialog which does not resize well.
Jan, did you create pseudo localized bundle files and then put into localized jar file and then run using 16 pt font in ja locale ? if not, then its not the testcase; this was mentioned in some recent comment below. let me know names of product jars that have these msgs/labels of the props and I'll send you such pseudo localized ja jars and you can run in ja locale at 16 pt font and see update - what is being seen now as problems resize are: source tab source binary format dropdown does not show default item completely also includes/excludes button not show text completely libs tab java platform dropdown default item not show completely run tab config dropdown not show default item completely web start tab code base dropdown not show default item completely and the extensions button not show completely ken.frank@sun.com
Hi Ken! I see where the problem might be - I have found it using one hint you sent: > the strange thing is, for the run section, if pick the customize option from the IDE window itself, > on the toolbar, where the dropdown is, the props window does show ok; no resizing problems vs the > problems seen when invoking project props from project menu. You were not fully right in this - there is still the same problem, but it is not so visible... This is what happens: Once you open the Properties dialog, dialog's dimensions are computed so that every component of the currently selected tab (!!!) fits well in the dialog. This is why Run section looks OK when it is invoked from the toolbar. However, if you switch to another tab (for example from Sources to the Run tab), dialog might become too small (which happens when you invoke properties using for example the context menu in the Projects view). I think there is some reason behind this "do-not-resize-dialog" solution: Dialog definitely should not change its dimensions once it is invoked (it should not resize when you select different tab) without direct user's resize action. It would be very confusing if the dialog changed its dimension when user switch to some other tab... Solution would be to compute the numbers maxWidth and maxHeight over all tabs (Sources, Groovy, ..., Application, ..., Formating - btw Formating tab suffers from the issue the most - check it) and then use these values for the dialog's dimensions. I do not know how difficult this would be, I will discuss this with Milan Kubec tomorrow... In any case, I think this issue does not deserve to be P2, although the priority guidelines might suggest this. The workaround is currently quite bearable, default dimensions are set quite reasonably so that the impact of this problem is minimized and - last but not least - when I meet issue like this (...yes, sometimes it happens...), I just resize the dialog manually by a few pixels, without having a big problem with this solution (of course it would be better if I didn't have to do that...). I would personally (according to my taste) suggest to set the priority of this I18N issue to P3. What do you say, Ken? With regards, Petr Dvorak
Petr, thanks for the good explanation ! I do see that its challenge with a multi tabbed dialog like project props, if the rule is to not have the entire dialog resize when go to another tab, then it makes it more challenging so that the items of any one tab resize ok within it. But couldn't some solution be to make original dialog size as big as would be for largest tab though I don't know it that is possible. I do know that solutions have been done in past for such multi tabbed dialogs but I don't know how they approached it. as to changing priority, lets leave it at p2 for now until after your discussion with Milan and to get your feedback on what I've written above. ken.frank@sun.com
Hopefully fixed. The dialog will resize according to each panel preferred size and the new size will be preserved and used next time. http://hg.netbeans.org/main/rev/abdd15a33101
solaris ja locale, using pseudo localized, 0727 trunk zip, using 14 pt font - it all looks good and things mentioned in my last comment that still did not resize, the all look all fixed now. ken.frank@sun.com
The fix for this issue caused issue 153877 which seems to be a worse situation. I'm trying to address it, and thought I would track down the issue where this change occurred to try to get some perspective as to the issue. Please review issue 153877.