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 100175 - I18N - some possible hardcoding of size of some windows or dialogs or font names or sizes
Summary: I18N - some possible hardcoding of size of some windows or dialogs or font na...
Status: VERIFIED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: visualweb (show other bugs)
Version: 6.x
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: Ch Nguyen
URL:
Keywords: I18N
Depends on:
Blocks:
 
Reported: 2007-04-06 02:44 UTC by bugbridge
Modified: 2007-12-07 16:41 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
file (23.84 KB, text/plain)
2007-07-10 02:30 UTC, Ken Frank
Details
dataconnectivity_dialogs_removed (16.30 KB, text/plain)
2007-07-18 02:36 UTC, John Baker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugbridge 2007-04-06 02:44:01 UTC
Original status: 1-Dispatched; Suggested Status: NEW

Original Target Release: shortfin_dev; Suggested Target Milestone : 5.5


Original submitter: kfrank

Description:
Code scanning of trunk shows some usage of hardcoding of 
Minimum and Preferred size of some windows or dialogs,
and sometimes, such usages can cause the windows/dialogs
to not dynamically resize when needed, for example when user runs using a larger
ide font size or when localized messages/labels are longer than they would be in
english - and users should
not need to manually resize most windows or dialogs to be able
to see all the information presented (some exceptions are jtable columns
and main ide windows like explorer, properties, etc)

I realize some of these usages might be ok
but the code scanning is just looking for patterns and also does 
not know what code is unused.

In other other products/packs, some of these usages were
actual problems, so thats why filing here also.

Creator engineering has approved that these be filed.

A file is attached that has these possible problems found for this
module.

ejb
Comment 1 Winston Prakash 2007-07-10 00:56:25 UTC
The attachment is missing.
Comment 2 Ken Frank 2007-07-10 02:26:07 UTC
I did this check again for nb6 - its not an exact check since for fonsize looks only
for setFont calls that hardcode a font size (or non std font name) - the results are below

for setting hardcode of a windows size, only looks at setPreferredSize or setMaximumSize
with hardcoded numbers; I dont think all such instances mean a windows size is hardcoded and will
not resize but at least the info is here and can be evaluated - attached.

and also there are probably results that are from unused code.

if there are other api calls that vwp uses to set font sizes, names or window/dialog sizes,
please check code for those also to make sure not hardcoded.


Here are the possible hardcoded font sizes:

       datasourceHeader.setFont(new java.awt.Font("Dialog", 0, 12));
        message.setFont(new java.awt.Font("Tahoma", 0, 13));
        dataconnectivity

        jLabel3.setFont(new java.awt.Font("Dialog", 1, 24));
        designer

        lblTitle.setFont(new java.awt.Font("Dialog", 1, 14));
       lblParameters.setFont(new java.awt.Font("Dialog", 0, 12));
       websvcmgr

ken.frank@sun.com
Comment 3 Ken Frank 2007-07-10 02:28:05 UTC
is Tahoma a standard jdk font name ?

BTW am changing the subcat to other since these are found in various parts of vwp - 
can they be assigned to correct developers thru other way like mails to dev team or
at dev meeting ?

ken.frank@sun.com
Comment 4 John Baker 2007-07-10 02:29:30 UTC
which dialog has the issue? 

please provide the netbeans module name and class name
Comment 5 Ken Frank 2007-07-10 02:30:29 UTC
Created attachment 44858 [details]
file
Comment 6 John Baker 2007-07-10 03:17:35 UTC
there are other modules listed in the attachment 

please create a separate issue for each module
Comment 7 Ken Frank 2007-07-10 04:18:59 UTC
sorry, I thought I had changed the subcat to other - am not going to be able to file a separate
issue for each - I think this could be sent to a dev alias or discussed at a dev team - I'll
ask Chau for her advice on this.

ken.frank@sun.com
Comment 8 John Baker 2007-07-11 21:28:45 UTC
partial fix:
remove unused dialog,
visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnectivity/datasource/NoSelectedServerWarning.form
   visualweb/dataconnectivity/src/org/netbeans/modules/visualweb/dataconnectivity/datasource/NoSelectedServerWarning.java
Comment 9 Ken Frank 2007-07-13 18:35:01 UTC
the attachment is from searching nb6 visualweb code; i changed the version
to 6.0

ken.frank@sun.com
Comment 10 Ch Nguyen 2007-07-13 19:32:47 UTC
Here are the owners for this issue:
Edwin: complib, ejb
JohnB: dataconnectivity
PeterZ: designer
Sandip: Insync
Winston: jsfsupport, propertyeditors, webui, xhtml
Joelle: palette
PoTing: project
Quy: Websvc
Chau: extension_core

If you not the right owner, please let me know.  Thanks.
Comment 11 _ potingwu 2007-07-13 21:14:17 UTC
The only 2 coding under 'project' are "importpage" and "jsfportlet" modules. They are both not active in the product.
Comment 12 Ch Nguyen 2007-07-16 18:23:45 UTC
Fix for extension_core:

Checking in nbbuild/cluster.properties;
/cvs/nbbuild/cluster.properties,v  <--  cluster.properties
new revision: 1.346; previous revision: 1.345
done
Checking in visualweb/extension_openide/nbproject/project.xml;
/cvs/visualweb/extension_openide/nbproject/project.xml,v  <--  project.xml
new revision: 1.7; previous revision: 1.6
done

I'm assigning to Gowri for fixing the modules in the Components area. Everyone else, feel free to fix your areas without
owning this bug.  If this light-weight process doesn't work, I will have to create individual sub-bugs for this issue. 
Thanks.
Comment 13 Winston Prakash 2007-07-16 20:10:05 UTC
The maximum size should be removed but not setPreferredSize(). Some layouts like Gridbag layout collapses the 
panel if preferred size is not specified. In such case preferred size acts a hint to the layout. 
So don't remove preferred size arbitrarily. Remove it only if specific  cases where setting preferred 
causing problem are reported and preferred size could be removed. I've noticed removing preferred size
worked OK on Windows JVM for Gridbag layout, but totally collapsed on MAC JVM. So caution need to be
exercised.
Comment 14 Joelle Lam 2007-07-17 19:28:47 UTC
The palette uses setPreferredSize and is variable according to the screenWidth.  No changes are necessary for Palette. 
I guess we are just supposed to assign it to the next person?  PoTing, you may want to look at it for project before you
leave.
Comment 15 _ potingwu 2007-07-17 19:48:23 UTC
> The only 2 coding under 'project' are "importpage" and "jsfportlet" modules. They are both not active in the product.

Project is clear.
Comment 16 Ch Nguyen 2007-07-17 22:12:53 UTC
Edwin, can you look into this for ejb and complib?  Then assign it to the next person on the list above.
Comment 17 _ edwingo 2007-07-17 23:13:27 UTC
I'm aware of this issue but am working on a Mac bug so could I look at it after? I'll assign it to the next person on
the cc list so I don't hold this task up.
Comment 18 _ gowri 2007-07-17 23:40:04 UTC
I have fixed all the hard coded maximum sizes in jsfsupport, propertyeditors and webui modules. The preferred sizes are
required to keep as they are based on the screen width. 

I am off this bug and someone else in the list can take over this bug.
Comment 19 _ potingwu 2007-07-17 23:49:11 UTC
As I said, project does not have any need for fixing this issue. The third times I said.
Comment 20 Ch Nguyen 2007-07-17 23:57:16 UTC
Gowri and all, please include the cvs checkin info to this bug or add a comment that you're done, so that we can pass it
on to the next person.

At this time, Po-Ting, Gowri, Joelle and Chau are done.  Assigning to John since his comment indicated that he only got
partial fix.  Then please pass it to PeterZ, Quy or Sandip next. Edwin last.
Comment 21 _ gowri 2007-07-18 00:19:31 UTC
These are the files that I modified to fix this bug. I thought of attaching the email link but I didn't receive any cvs
auto commit email. Thats why I am listing the files that are modified.

/visualweb/propertyeditors/src/com/sun/jsfcl/std/property/ChooseManyReferenceDataPanel.java  1.2
/visualweb/jsfsupport/designtime-1.2/src/org/netbeans/modules/visualweb/faces/dt_1_2/component/html/HtmlDataTableCustomizerColumnsPanel.java
 1.2
/visualweb/jsfsupport/designtime/src/org/netbeans/modules/visualweb/faces/dt/std/table/HtmlDataTableCustomizerColumnsPanel.java
 1.3
/visualweb/propertyeditors/src/org/netbeans/modules/visualweb/propertyeditors/css/StyleBuilderPanel.form  1.3
/visualweb/propertyeditors/src/org/netbeans/modules/visualweb/propertyeditors/css/StyleBuilderPanel.java  1.3
/visualweb/jsfsupport/designtime-1.1/src/org/netbeans/modules/visualweb/faces/dt_1_1/component/html/HtmlDataTableCustomizerColumnsPanel.java
 1.2
/visualweb/propertyeditors/src/org/netbeans/modules/visualweb/propertyeditors/StandardUrlPanel.java  1.3
/visualweb/propertyeditors/src/org/netbeans/modules/visualweb/propertyeditors/StyleClassPropertyPanel.java  1.3
/visualweb/propertyeditors/src/com/sun/jsfcl/std/URLPanel.java  1.2
Comment 22 John Baker 2007-07-18 02:36:40 UTC
Created attachment 45275 [details]
dataconnectivity_dialogs_removed
Comment 23 John Baker 2007-07-18 02:37:45 UTC
Ken, lots of changes have been made. Please re-run the tool
Comment 24 Ch Nguyen 2007-07-18 05:58:25 UTC
We're not done yet.  Let's pass it on to PeterZ.
Comment 25 Peter Zavadsky 2007-07-18 09:19:15 UTC
Fixed in designer/jsf.

Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/ErrorPanelImpl.form;
/cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/ErrorPanelImpl.form,v  <-- 
ErrorPanelImpl.form
new revision: 1.2; previous revision: 1.1
done
Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/ErrorPanelImpl.java;
/cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/ErrorPanelImpl.java,v  <-- 
ErrorPanelImpl.java
new revision: 1.5; previous revision: 1.4
done
Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/RenderErrorPanelImpl.form;
/cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/RenderErrorPanelImpl.form,v  <-- 
RenderErrorPanelImpl.form
new revision: 1.2; previous revision: 1.1
done
Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/RenderErrorPanelImpl.java;
/cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/RenderErrorPanelImpl.java,v  <-- 
RenderErrorPanelImpl.java
new revision: 1.6; previous revision: 1.5
done


Please, next time file separate issue per each module. 
This way it is 
1) very hard to find out what actually is relevant to particular module (too many comments dealing with other modules), 
2) it takes too long time until the issue is processed in sequence (it took almost 3 months until the issue reached my
module, i.e. until I've learned about it [the CC is not enough]).

Passing to Quy (who is next in the row).
Comment 26 _ edwingo 2007-07-20 23:03:25 UTC
I looked at the two from the "complib module". This one is OK:
./complib/src/org/netbeans/modules/visualweb/complib/ui/CompLibManagerPanel.java. The following has been fixed:
./complib/src/org/netbeans/modules/visualweb/complib/ui/HelpSourcesDetailPanel.java. Unfortunately, I already lost the
CVS output so can't paste it here.
Comment 27 Quy Nguyen 2007-07-21 00:10:26 UTC
Removed the hardcoded fonts and setSize() code in websvcmgr.

/cvs/visualweb/websvcmgr/src/org/netbeans/modules/visualweb/websvcmgr/ui/Bundle.
properties,v  <--  Bundle.properties
new revision: 1.6; previous revision: 1.5
done
Checking in src/org/netbeans/modules/visualweb/websvcmgr/ui/MethodExceptionDialo
g.java;
/cvs/visualweb/websvcmgr/src/org/netbeans/modules/visualweb/websvcmgr/ui/MethodE
xceptionDialog.java,v  <--  MethodExceptionDialog.java
new revision: 1.4; previous revision: 1.3
done
Checking in src/org/netbeans/modules/visualweb/websvcmgr/ui/ResultViewerDialog.j
ava;
/cvs/visualweb/websvcmgr/src/org/netbeans/modules/visualweb/websvcmgr/ui/ResultV
iewerDialog.java,v  <--  ResultViewerDialog.java
new revision: 1.2; previous revision: 1.1
done
Checking in src/org/netbeans/modules/visualweb/websvcmgr/ui/TestWebServiceMethod
Dlg.form;
/cvs/visualweb/websvcmgr/src/org/netbeans/modules/visualweb/websvcmgr/ui/TestWeb
ServiceMethodDlg.form,v  <--  TestWebServiceMethodDlg.form
new revision: 1.4; previous revision: 1.3
done
Checking in src/org/netbeans/modules/visualweb/websvcmgr/ui/TestWebServiceMethod
Dlg.java;
/cvs/visualweb/websvcmgr/src/org/netbeans/modules/visualweb/websvcmgr/ui/TestWeb
ServiceMethodDlg.java,v  <--  TestWebServiceMethodDlg.java
new revision: 1.5; previous revision: 1.4
done
Comment 28 _ sandipchitale 2007-07-23 19:54:19 UTC
Partial Bug Fix.

Fixed the (redundant) hardcoding in 
org/netbeans/modules/visualweb/insync/faces/refactoring/FacesRenamePanel.java\nLooks like the 
org/netbeans/modules/visualweb/insync/live/DesignBeanNodeHelper.java no longer has the code mentioned in the log.

Checking in FacesRenamePanel.form;
/cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/faces/refactoring/FacesRenamePanel.form,v  <--  
FacesRenamePanel.form
new revision: 1.2; previous revision: 1.1
done
Checking in FacesRenamePanel.java;
/cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/faces/refactoring/FacesRenamePanel.java,v  <--  
FacesRenamePanel.java
new revision: 1.3; previous revision: 1.2
done

Passing back to Chau.
Comment 29 Ch Nguyen 2007-07-23 20:18:32 UTC
I believe we're done now.  Thanks all.
Comment 30 Ken Frank 2007-10-18 18:28:27 UTC
verified.