classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comment to 0.19


From: theUser BL
Subject: Re: Comment to 0.19
Date: Mon, 07 Nov 2005 14:10:09 +0000

Hmmm... then there are some other things which must also corrected.
For example the text in the Message-Dialogs (like Error-Massage) is in the old Classpath (until 0.18) right-justified. In the actual Classpath (0.19) it is centered and in Suns Java it is left-justified. I think the actual centered version looks better like Suns version. But as you said, then the Classpath-version is wrong.

In my opinion, yes it is wrong. I think our goal should be that you cannot tell the difference between a screenshot from GNU Classpath and the equivalent from Sun's implementation (excluding fonts, where I don't believe it is practical to achieve an identical look).

You mean between GNU Classpath and Java 1.4, right?
Because the Metal LaF is from Java-Version to Java-version different.

In Swing 1.0.3 there was the LaF in com.sun.java.swing.plaf.MetalLookAndFeel.

With the JFC 1.1.1 it changed to javax.sun.java.swing.plaf.MetalLookAndFeel.
Additional the look of the drawn internal windows-frames changed.

With Java1.2 the spaces between the words in the Menu-titles becomes bigger.

With Java 1.3 the spaces becomes smaller. So Sun takes his idea back.
I think in Java1.3 Sun changed additional the the JTree. First the folders are only opend and closed with Enter. After Java 1.3 it opend also with the right cursor button and closed with the left cursor button. Additional it becomes lines between the folders and leafs, which draw the tree.

I think in Java 1.4 there changed the color of the Text in a border or how it is called. Befor it has the color dark violett and since Java 1.4 it is black.

In Java 1.5 the standard LnF is Ocean. And the other LnF of Metal becomes the name Steel.

In the Java 1.6 previews now, it looks that Sun again changed the UI of the JTree. If you are on a folder which is closed in Java and you click the right cursor button, then it opens. If it is open and you click on the key it go to the next sub-folder or to a leaf. But is it on a leaf and you click on the right cursor-button then on Java 1.4 and 1.5 it go to the next leaf or next folder. But with the Java1.6ea preview version, it do nothing.

And to mention your screenshot-illustration: I say, if there existing a screenhost of a Java-program with the Metal-LaF and on the Screenshot is a Menu, a border, a tree and so on, then it is possible to say, which Java-version was used.


An additional problem with the ScrolbarDemo (which is a bug) is, that the four scrollbars on the top of the demo are changing the size by changing the size of the window in GNU Classpath. But in Suns Java version, which seems to be the right one, there chnage also all Scroolbar the size only the four at the top not.
But I can not send bug-report because I don't know how to do it.

Click "Report it" on this page:

http://www.gnu.org/software/classpath/bugs.html

Hmmm... I think, it would be better if other people doing it.


A additional bug is with programs which have instead a
  public class myClass extends JFrame {}
a
  public class myClass extends JPanel {}
or
  public class myClass extends JApplet {}

If in this Class is a Button for example and clicked it or a Scrollbar and moves it or so, you can't see any action. It seems, that the program don't react to your input. But if you move a window temporaly over your Java-window or move it temporaly outside the screen you can see after that the change - in GNU Classpath. Suns Java-Version react direct. There is no different between a program with JFrame, JPanel and JApplet.

I haven't looked at this, but if you have a small sample app that shows the problem, post it in a bug report.

Please send you or any body other the bug report.
At
http://user.web-gear.com/theuserbl/ButtonDemo.jar
I have a example, which shows it. In this case this program used JApplet and JPanel. It is the same program like "ButtonDemo.java" from the GNU Classpath-Examples. It only used JApplet and JPanel instead of JFrame. And on Suns Java, it runs like the original one. Only on GNU Classpath not. There the window updates only if a other window was temporaly over it, the window-size have changed or something else. But I think, it is not a problem of Swing. The problem begins already with AWT. If you using Applet instead of Frame, you have the same problem, if you draws something and want to change it with a click on a button or so. Btw. The SourceCode (*.java-fikles) are in the executable *.jar file included.

Greatings
theuserbl






reply via email to

[Prev in Thread] Current Thread [Next in Thread]