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
_______________________________________________
Classpath mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath
