Community
Participate
Working Groups
Our license agreement does not display in the Feature License panel of the Install wizard on HP-UX. The license is quite long, but does display properly on other platforms -- including other UNIX platforms such as Solaris/Motif and AIX. I don't know what the size limit is, but I tried a very small license and it did display properly. But IBM legal has given me the license to be used and I can't edit it down.
Donald, I don't think we have any limit on the size of license and it does not look like it is an issue in update at all, since it displays fine on other platforms. That said i will try to get hold of some HP machine and check this out since it is definatly not a good thing. Can you please tell me how big is your license and does eclipse license displays fine on that HP-UX?
Donald, we need your help in debugging because we don't have a local HP-UX machine. Try the following: 1) Go to SWT snippets page and locate the Text snippet. Verify that it runs, then modify it by setting the full license text to it. See if it displays it OK. You can try this snippet: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet117.java 2) Passing 1), create a small Java code that loads the license from feature.properties (I think this is how you specify it, right - as a long text in feature.properties referenced from feature.xml). The goal of the test is to find out if there is a limit to the line lengh for *.properties files on HP-UX + the JRE you are using.
Steve R. followed Dejan's instructions as requested and got the following results in Eclipse 3.2M6: [I used] the license file in question. I read and appended each line into a StringBuffer, and then attempted to setText() to the buffer.toString(). That failed (blank text widget). I verified that I could set the widget to just the first line of the file. That worked. I tried counting lines as they were read and appended, and tried setting the widget at various numbers of lines. I also printed a character-count when doing this, and saw that somewhere between 820 and 830 lines, the limit was hit. So the problem seems to be one of sheer length of the license text.
Steve, see above re the limit of text that can be set in the Text widget on HP-UX. Are you aware of this limitation?
This looks like a bug in SWT. Please attach the file and move it over to us. Thanks.
Donald, since the offending text is a product license, can you attach a text of an equivalent size that causes the same problem to happen? Can you sync up with Steve R. to hand you over the sample code he used to hit the limit of 820-830 lines?
Created attachment 39790 [details] I believe this is the license text in question Please let me know if this does not reproduce and I will ensure that this is the correct license text.
Moving to SWT - see if the attached text is causing problems for the multi-line TEXT widget on HP-UX.
The following simplified Snippet117 works for me without hitting a text limit. In comment 3 it looks like doing something like this failed for Steve R. Can you try this snippet on your hpux (just change the FILENAME constant to point at your local copy of the license text) and see if the full text displays for you? public class Snippet117 { static final String FILENAME = "/bluebird/teamswt/ggayed/license.txt"; public static void main(String[] args) { Display display = new Display(); String string = null; try { FileInputStream stream = new FileInputStream(FILENAME); int length = stream.available(); byte[] bytes = new byte[length]; stream.read(bytes); stream.close(); string = new String(bytes); System.out.println("I read in:\n" + string); } catch (Exception e) { e.printStackTrace(); return; } Shell shell = new Shell(display); shell.setLayout(new FillLayout()); final Text t = new Text(shell, SWT.MULTI | SWT.V_SCROLL | SWT.H_SCROLL); t.setText(string); shell.setSize(200, 200); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Just FYI, here is the code that creates the license text in the license page (package org.eclipse.update.internal.ui.wizards, file LicensePage.java, line 90): text = new Text( client, SWT.MULTI | SWT.BORDER | SWT.V_SCROLL | SWT.H_SCROLL | SWT.READ_ONLY); GridData gd = new GridData(GridData.FILL_BOTH); if (multiLicenseMode) gd.horizontalSpan = 2; text.setLayoutData(gd); text.setBackground(text.getDisplay().getSystemColor(SWT.COLOR_LIST_BACKGROUND));
...and this is the code that sets the license text: private void showLicenseText() { if (!multiLicenseMode) { text.setText(jobs[0].getFeature().getLicense().getAnnotation()); return; } TableItem[] selectedItems = table.getSelection(); if (selectedItems.length == 0) { text.setText(""); //$NON-NLS-1$ } else { Object data = selectedItems[0].getData(); text.setText((data == null) ? "" : (String) data); //$NON-NLS-1$ } }
We have just recently discovered that this is not an Eclipse defect, but appears to be a problem when using X-11 remote display tools. One of our engineers had a problem logging in using cygwin to HP-UX, and found out that a font server needs to be running on the HP-UX machine for things to display properly using one of these tools. Apparently the extent of the problem varies depending on which tool (exceed, vnc, cygwin...) is being used, so that's why we thought the problem only involved the license display.
Ok, can we close this bug then as WORKSFORME?
I think we can. I will note that Peter Hack points out that it is odd (and I agree) that the lack of a font server would cause such inconsistent results across various remoting apps... If the font server fixes the problem, in the absence of a font server why would the amount of text affect whether or not any is displayed? I would think that it would never display. However, it does work now, so I won't complain :-)
WORKSFORME
Please reopen this defect. It turns out after some confusion that the problem still exists in the license display widget. There is not a problem when running natively on HP-UX, but only when running Eclipse through an x11 remoting tool like Exceed or cygwin.
I forgot to add that we tried the code snippet recommended by Grant and it did not fix the problem.
reopening
On a hunch, I tried replacing CR with CR/LF in the example snippet, but this did not make the problem occur when run locally. I'll get hold of cygwin in order to try to reproduce this as described. This will likely not be addressed for 3.2 because it's too late in the release cycle, and we believe that a problem that's caused by using a remote terminal is not as major as one that happens when working on a box locally.
We're looking into this again. Stand by.
The problem happens because the license file has three non-ascii characters. It is not a size limitation. When running remotely, somehow the default font of the widget is a FONTSTRUCT instead of a FONTSET and a different code path runs which calculates the code page of the font badly. It calculates iso8859-1, but HPUX expects iso88591. So the conversion from unicode to the font encoding fails, resulting in an empty string. We have a fix for this problem, but it is also possible to avoid it by removing the non-ascii characters from the license file. If the string to convert has only ascii characters, the OS conversion calls are not used. There are two characters following this sentence (quotes not included): "The limitations apply to the extent they are not prohibited under " and one just before: "15,000"
I am not sure the characters will be printed fine in bugzilla, but here are the actual characters: £, §.
Great find! Let me see if we can get permission to remove those characters. Thanks.
We can live with the workaround for now. Can a fix be scheduled for an upcoming release (3.2.1, 3.3)?
Changing ownership since Silenio investigated this fix.
Created attachment 41495 [details] Here is the path to be released after 3.2 ships
Patch released in HEAD (3.3) > 20060726.
*** Bug 105447 has been marked as a duplicate of this bug. ***
