Re: Comment to 0.19

[theUser BL]

> > 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