Skip to main content

JXTable V1.6.5 - alternate row colors

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
27 replies [Last post]
wzberger
Offline
Joined: 2004-08-31

Since V1.6.5 alternating row colors do not appear in a JXTable with checkbox renderer - looks like a bug.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kleopatra
Offline
Joined: 2003-06-11

darn - it's a regression to core misbehaviour in Nimbus ;-(

Was introduced by fixing http://java.net/jira/browse/SWINGX-1513 (support fully transparent renderers) - back to square one.

As a quick fix, you can inject the old (1.6.4) version of JRendererCheckBox - it had been working for years, that is not showing the core bug, so no surprises expected. Hoping ..

Thanks for the heads up!
Jeanette

wzberger
Offline
Joined: 2004-08-31

I've already tested the 1.6.4 renderer and it seems to work fine.

Cu

kleopatra
Offline
Joined: 2003-06-11

filed a blocking issue:

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

will "fix" by reverting to 1.6.4 rendering checkbox, not very satisfying, sigh ...

kleopatra
Offline
Joined: 2003-06-11

a first analysis seems to indicate that I .. ehem ... forgot to set the JRendererCheckbox' opacity to true. Doing so, fixes all visual glitches in all core LAFs in both jdk6 and 7.

That said: there's still a loop-hole (not really testable without well-behaved synth LAF). Here's my current take of it.

A base requirement is to support striping (aka: filling the background) and swingx painter on top of the background (Issue #837) plus the normal forground painting, in pseudo-code something like

if (opaque)
    fillBackground
paintSwingXPainter
paintForeground

The first and last line is handled in componentUI.update (isynth-based LAFs have the middle line as well, only it's paintCorePainter) , there's no direct way to put the swingx painter in-between. The hack is to take over the background filling in the rendering component and then jump into componentUI.paint

if (opaque)
    fillBackground
paintSwingXPainter
ui.paint

and that's the hole: if synth-based lafs do their background striping (or other background painting) via a core painter, that painter is not called because we by-pass the update.

Feedback highly welcome :-)

Cheers
Jeanette

wzberger
Offline
Joined: 2004-08-31

Does the described painting issue also affects JRendererCheckbox or does it belong to JXPanel only?

kleopatra
Offline
Joined: 2003-06-11

the details described here are JRendererCheckbox only - the general base problem is probably similar in JXPanel, though with a different implementation (guessing, not yet overly familiar with the current JXPanel, Karl is the expert with that :-)

Good night
Jeanette

wzberger
Offline
Joined: 2004-08-31

IMHO simply call ui.update instead of ui.paint - so the user is able to decide which painter is used and benefits from both frameworks. My tests with a modified renderer and jxpanel seem to work fine.

kleopatra
Offline
Joined: 2003-06-11

hmm .. ui.update fills the background, thus painting over a swingx painter.

Anyway, for a JRendererCheckBox, all the tricksery will happen only if there _is_ a swingx painter (there never is by default), so the user can choose to not use it.

Need some further tests (slowly understanding why I didn't notice the obviously broken rendering checkbox) - current standing is that the not-seeing was a testing artefact: starting a visualCheck with a LAF other than Nimbus installs its opacity to true (all well in that case), then switching the running visual check to Nimbus keeps the opacity to true, all looks well. Starting with Nimbus installs the opacity to false, thus looses the striping - obviously didn't do that at the crucial time before committing.

Testing, testing, testing ;-)
Jeanette

wzberger
Offline
Joined: 2004-08-31

For being more convenient additionally set the opacity to false when a SwingX painter is installed and provide a short hint in the API doc ;-)

kleopatra
Offline
Joined: 2003-06-11

btw: do you see any unwanted side-effects with the JRendererCheckbox forced to opaque?

Thanks
Jeanette

kleopatra
Offline
Joined: 2003-06-11

actually, that's already done, kind of: if we have a swingx painter and want to fill the background (aka: striping), the background is filled in the checkbox painting and its isOpaque returns false while delegating the foreground painting to the ui (to hinder it from painting over the painter).

The thingy to document might be that users can have either swingx or core (ui-supplied) "background" painters, the outcome of having both is not well defined. If there are both, the winner depends on the opacity:

- if true, the renderer takes over the background filling and the core painter is ignored (because never called due to bypassing ui.update)
- if false, the swingx painter is applied then the core painter gets its chance and may or may not fully obscure the swingx painting

Cheers
Jeanette

wzberger
Offline
Joined: 2004-08-31

No side effects so far when opacity is enabled.

Not quite clear why you don't want to let ui.update do the job with enabled opacity. It takes care about the background filling and will call the core renderer.

Cu,
Wolfgang

kleopatra
Offline
Joined: 2003-06-11

hmm ... don't quite understand why you keep suggesting that (probably missing something obvious ;-): ui.update is the same as calling super.paintComponent, with opacity set the ui _paints over_ the swingx painter because it's called later than the painter.

**Edit** okaay ... might get your point: iff we have a swingx painter _and_ opaque == true, then the logic is to fill the background, paint swingx painter, fake opacity == false and call ui.paint - in that case we could just as well call ui.update as long as the ui doesn't fill the background if opaque == false - is that somewhere near what you mean?

Cheers
Jeanette

wzberger
Offline
Joined: 2004-08-31

Yes, that's why I would also set opacity to false when a SwingX painter is installed. BTW Generally if you want to support translucency for a (SwingX) painter, the component has to be non-opaque to avoid rendering artifacts.

kleopatra
Offline
Joined: 2003-06-11

good, so we are getting nearer to a solution :-)

BTW, setting opacity to false looses the striping, that's why we need to take over filling the background.

On to more testing - any chance you have some sample ready with a core (synth) painter on a renderer? Having a hard time to come up with something to test having both swingx and core painters at the same time.

yeah, translucency is the next problem to solve ...

Thanks
Jeanette

wzberger
Offline
Joined: 2004-08-31

Please find a test attached. Note: Add an image to the test and modify the imagepath currently "/test/synth/checkBoxBackground.png"

kleopatra
Offline
Joined: 2003-06-11

great example - thanks!

Below are screenshots w/out swingx painter, hooking into paint/update and not/opaque

- general setup is your example
- three rows selected (two with the core background painter, aka: selected checkbox, one without)
- the swingx painter is a solid red MattePainter applied to one of the rows with selected checkbox. This is the really interesting row, as we have both a swingx and a core painter

The state/logic of the JRendererCheckbox used is:

- explicitly set to opaque as default
- if no swingx painter applied, simply delegate to super
- if swingx painter and !opaque: paint swingx painter, then delegate to super
- if swingx painter and opaque: fill background, paint swingx painter, fake !opaque and hook into ui.paint or ui.update

When hooking into paint, the core painter is (expectedly) lost, but hooking into update with a faked !opaque shows both. Nice :-)

So tend to hook into the update (or delegate to super, which is the same) - if there are no objections?

Thanks
Jeanette

hmm ... can't attach the files, will try in jira

wzberger
Offline
Joined: 2004-08-31

Really appreciate the usage of update() instead of paint() - hope it will also find it's way to JXPanel.

BTW: Any release plans for V1.6.6?

Thanks,
Wolfgang

kleopatra
Offline
Joined: 2003-06-11

after thinking again: hooking the rendering component paintComponent into ui.update will break backward compatibility ;-) Plus the visual outcome of having both the swingx painter and the core painter is hard to predict and might not always be entirely pleasing

Considering 1.6.4 as the last version that worked as expected, I think the default behaviour (after the bug fix) should behave as that version - which is to use the swingx painter if available (and hook into ui.paint) and just call super if not available.

For maximum flexibility, we could add a configurable property (UIManager? per-renderer?) to conditionally hook into the ui.update - then the dev is forced to set it explicitly if s/he wants both, and is warned that she might have to cope with the outcome.

A LAF provider like you might enable that option for the given LAF, if you feel confident.

Still musing about the other open point: semi-transparent background colors in the rendering component. Not entirely certain if not playing by the rules (that is report opaque == true nevertheless) is such a big problem on the rendering component: artefacts are expected if the table itself is playing dirty, a dirty renderer on top of a clean table shouldn't do much harm. Would love to see examples which proof me wrong, though :-)

Cheers
Jeanette

BTW, no release plans yet - first we need to solve the painting issues, then decide if/when to release. The JXPanel problem is harder to solve, as there we _have to_ tackle the transparency issues.

wzberger
Offline
Joined: 2004-08-31

Generally an additional UI-property would be OK. However, for the JXPanel issue both painters have to work together.

Because of the artefacts I had the same thoughts in this special case - just wanted to be sure you are aware of.

Thanks,
Wolfgang

tonya_rae_moore
Offline
Administrator
Joined: 2011-05-20

Your comment was hung in the spam filter. If this happens, send me an email directly and i can release it.

Tonya R. Moore
Assistant Community Manager

fnikola
Offline
Administrator
Joined: 2008-02-27

comment on tonya's post - 827470

kleopatra
Offline
Joined: 2003-06-11

trying again ...

kleopatra
Offline
Joined: 2003-06-11

always barks at the second attachment ... so here we go again ...

kleopatra
Offline
Joined: 2003-06-11

this forum is driving me crazy: "the comment you are replying to does not exist" ... doohhh - does anybody see my last comment, from 19. Feb (I do, but can't reply to it and don't dare trying to edit it):

http://www.java.net/forum/topic/javadesktop/java-desktop-technologies/sw...

If not, I'll have to post it again. Assuming it is visible, here's the current state (in my head, still swaying back and forth, kind of :-)

One important aspect is internal consistency (if a swingx painter is available), which currently is not the case:

if (isOpaque()) {
     ...
     ui.paint(..)
} else {
     ....
     ui.update(...)
}

It should be the same hooking in both branches. Implication being, that on cleanup we do break backwards compatibility in one of the branches.

So we might go for the update always...

Just thinking aloud, against closing-in opaqueness of panel, mind and others (at least the wheather is improving, sun is shining for the first time in weeks)

Cheers
Jeanette

wzberger
Offline
Joined: 2004-08-31

Already received notifications but your comment from 19. Feb is not visible - just wondered why I was notified.

Cheers,
Wolfgang

wzberger
Offline
Joined: 2004-08-31

Another possibility is to delegate the background filling to the user who installs the painter - you could provide a simple helper method which can be called by the painter.