Skip to main content

SwingX 1.6.4 JXSearchField not rendering on OS X

7 replies [Last post]
fommil
Offline
Joined: 2006-11-26
Points: 0

Hi,

I just tried out the latest SwingX 1.6.4 staging release, and my JXSearchField's are no longer rendering on OS X (although the magnifying glass is there). If I type on where they should be, the white background and rounded borders appear, and continue to exist if I type, but once all text is removed and the focus goes elsewhere, the white background of the text area (with rounded corners) just disappears and leaves a gaping hole in my app.

Workarounds?

Regards, Sam

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08
Points: 0

Is this a regression? From the previous release? Or some earlier release?

Do you have a small, runnable test case?

Karl

kschaefe
Offline
Joined: 2006-06-08
Points: 0

I don't see how this can be a regression against 1.6.3, since the code that broke this was checked in as a fix for 1.6.1, cf. issue 1326. Possibly, Apple changed something from underneath us (not the first time) or it hasn't worked in over two years.

Given either possibility I don't think this is important enough to stop the 1.6.4 release. We have quite a few Mac painting issues that really need a dedicated Mac advocate to track down.

I'll let this percolate for another day or two, awaiting responses.

Karl

fommil
Offline
Joined: 2006-11-26
Points: 0

Standalone test case added to issue report

http://java.net/jira/browse/SWINGX-1508

This is definitely against 1.6.3 -> 1.6.4 as I just explicitly tested against both.

kschaefe
Offline
Joined: 2006-06-08
Points: 0

The only new change in that area seems unrelated to the AquaLookAndFeel painting code that I can dig up on the Internet. That is the change to make LabelField more of a renderer because it was causing huge CPU usage on some systems. Can you test with and without that change on your Mac and give some results? Also, could you help determine if the renderer-style change is the culprit, if there is some way to keep it and service Mac? Prompts are a CPU hog without the change.

Karl

fommil
Offline
Joined: 2006-11-26
Points: 0

(I hate java.net so much, just logged in and it redirected me to some random page - it was easier to use google to get back here than its incompetent navigation/search system. And I am sure I can expect an email in 5 minutes telling me that somebody - that would be me - has commented on my comment. And seriously, I've been a member for years and signed a contributor agreement: why oh why do I need to answer a maths question to post a comment? Aaaarggh! Please, please move to Google Code!)

Happy to do a check - just tell me what test case to run or what to put in my POM.

kschaefe
Offline
Joined: 2006-06-08
Points: 0

Can you check out the current source and load up the previous version of PromptTextFieldUI and run your code? Does it work? If so, can you attempt to remove both overrides of firePropertyChange in the current version and try again?

Thanks for any help as I don't have easy access to test on a Mac.

Karl

fommil
Offline
Joined: 2006-11-26
Points: 0

No, I can't check out the current source - this is java.net and utterly impossible to navigate.

I'll use the source - that comes with the 1.6.4 staging release - to set up a new NetBeans project and swap in the PromptTextFieldUI from 1.6.3.

It would be a lot easier if you were able to push out temporary maven packages for users to check against - it would really make bug verification a lot easier on the issue tracker too.

Can we please move this discussion to the issue tracker? java.net, and its unfit-for-purpose forum, makes me want to pull out my hair.