|
From: | David Gilbert |
Subject: | Re: Comment to 0.19 |
Date: | Sun, 06 Nov 2005 16:39:39 +0000 |
User-agent: | Mozilla Thunderbird 1.0.7 (X11/20051026) |
theUser BL wrote:
I did the work on the MetalScrollBarUI and related classes, and I took the approach of trying to match pixel-for-pixel the appearance of Sun's implementation (I know there are still a few things to fix). That way, we have a totally objective test of what is right and what is wrong. I think if we go down the route of trying to improve the aesthetics of the MetalLookAndFeel, then we start having to make subjective judgements about what looks best. Once you decide to do that, you might as well implement a new look and feel (like JGoodies).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). I don't think there is an official project policy on this though.
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
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.
And at the last, I wanted to mention, that it would be nice, if anybody integrates the JFileChooser in dem Swing-Demo program. In the Demo-program is nearly all in: Scroolbars, Buttons, ColorChooser and so on. Only JFileChooser isn't.
I've done some work already on the MetalFileChooserUI class (and related classes), but didn't get it working well enough for the 0.19 release. I hope to get something committed to CVS soon, and working really well for the 0.20 release.
Regards, Dave Gilbert
[Prev in Thread] | Current Thread | [Next in Thread] |