|
Replies:
26
-
Last Post:
Apr 2, 2009 12:51 PM
by: i30817
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
JTable-Zebra with one line ...
Posted:
Mar 21, 2009 1:15 AM
|
|
|
After implementing on my own over several hours, I stumbled more randomly in the DefaultTableCellRender about the key "Table.alternateRowColor". When you put
UIManager.put("Table.alternateRowColor", Color.PINK);
you get without any implementation a Zebra-table. Every other row is painted with PINK. 
I thought I share it, cause it seems ridiculous to not find the simple solution neither on a Google search nor in this Desktop-Forum.
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 21, 2009 4:46 AM
in response to: leo_test
|
|
|
Shaking my head in utmost fury ... so THEY did it again ... completely undocumented behaviour changes to be stumbled across by mere chance ... and at the same time those myserious moves to sun.* classes (what does DefaultLookUp that needs to be hidden from the public eye?) Already secretely preparing for IBM takeover since months ... ?
obviously, I'm ranting <g>
Jeanette
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 21, 2009 5:46 AM
in response to: kleopatra
|
|
|
The key is supported by Java6u10 and above.
I guess the DefaultLookUp class was made for key variations to support different component states and styles (Nimbus only).
I've recently stumbled across this class because some provided UI-properties won't appear.
Cheers,
Wolfgang
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 23, 2009 3:56 AM
in response to: wzberger
|
|
|
Then it's probably in the sun package due to no API changes in upgrades.
Anyway, it doesn't work with the default boolean cell renderer (just fueling kleopatra's ranting with this remark ;)).
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 23, 2009 4:23 AM
in response to: wzberger
|
|
|
Inspecting little bit closer the implementation I see:
if (background == null || background instanceof javax.swing.plaf.UIResource) {
Color alternateColor = DefaultLookup.getColor(this, ui, "Table.alternateRowColor");
if (alternateColor != null && row % 2 == 0)
background = alternateColor;
}
My remarks here are, when reviewing the code really closely:
- the DefaultLookup is called every time the Cell is repainted
- the DefaultLookup is even called, when it is not used (row %2 ==1)
Q1: Why is the color not saved in a variable instead looking up every time the cell is repainted? (I think there is as well the updateUI, which would recognize changes)
Q2: Does this constant lookup benefit to the time-delays measured here in this forums?
Q3: If the default Checkboxes do not work, do they use a different settings of color (i.e. NOT javax.swing.plaf.UIResource)?
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 23, 2009 5:02 AM
in response to: leo_test
|
|
|
q1: renderers should be as stateless as possible - so if there's a ui-dependent but hidden property, lookup at each round is the correct thing to do, IMO
q2: you know what I think about assumed performance bottlenecks Simply forget it until there are problems _and_ the cause is reproducibly measurable.
q3: haha ... my guess is they simply forgot to tweak the checkbox renderer (which is defined in the JTable) as well <g> That would be completely in line with the measurable code quality drop in Swing ...
CU
Jeanette
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 1:30 AM
in response to: kleopatra
|
|
|
add q1) I am little bit surprised about the fact, that the DefaultTableCellRenderer retrieves JTable-Properties. Since the method in which it is retrieved (getTableCellRendererComponent) has as well the parent, i.e. JTable, I wonder why it is not retrieved from the Table. To my understanding some object-related coding should split the properties to the class where it belongs to and not to some childs which retrieves the properties in a way around from the global settings.
I would have expected that there is something like JTable.getAlternateBackgroundColor(). But looking in the method, I am surprised, that there are more global items retrieved, like background- and forgroundColor. etc.etc.
The advantages in the approach I see is, that you do not have too many methods. The disadvantage is, that you cannot memorize them properly and have to retrieve it with DefaultLookup
add q2) Performance, I agree to some part. The DefaultLookup takes about 10 times longer then a lookup in a HashMap. AND the issue will only appear, when you display a lot of cells. So, not a big deal on a Desktop-machine, even with a lot of cells on a 30"-Monitor
Bottomline: I agree, there could be always a *better* coding-style, but as long as it works, who cares?
Out of curiosity: What about the applications on Handheld, Mobile, etc. ? Don't they use the same methods or is there something equivalent to JTable/DefaultCellRenderer?
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 2:06 AM
in response to: leo_test
|
|
|
beware: the whole point of a renderer is that it _has no concept_ of parent <g> By design, it's providing and configuring a rendering component. So yeah, the basic idea is to ask the target (f.i. the JTable) for its relevant properties at the time of configuration, which is in getXXCellRendererComponent. And that's where those properties "belong": to the concrete table instance, usable by slaves like renderers. Which must be stateless because they are widely shareable, across cells, columns and even several instances of the same target type.
It was a bad implementation decision (hindsight, partly, we all learn a bit every day  to extend JSomething for the defaults: this way the conceptual separation between a "provider of a rendering component" and the "rendering component" itself got lost. Not accidentally, SwingX has it clear-cut, and not accidentally, it's called ComponentProvider, and not accidentally, it's even more widely shareable across instances of different target types <g>
CU
Jeanette
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 24, 2009 6:58 AM
in response to: leo_test
|
|
|
swing@javadesktop.org wrote:
> My remarks here are, when reviewing the code really closely:
>
> - the DefaultLookup is called every time the Cell is repainted
> - the DefaultLookup is even called, when it is not used (row %2 ==1)
>
> Q1: Why is the color not saved in a variable instead looking up every time the cell is repainted? (I think there is as well the updateUI, which would recognize changes)
> Q2: Does this constant lookup benefit to the time-delays measured here in this forums?
I don't think this takes much time, though it may be an issue for large
tables. I do agree however that the lookup should be done only if (row
%2 == 0).
> Q3: If the default Checkboxes do not work, do they use a different settings of color (i.e. NOT javax.swing.plaf.UIResource)?
It appears they don't work because SynthBooleanTCR does not call super.
And even if it did, they should also be opaque to render the correct
background. I'm going to look for a bug on this.
--
Peter
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 1:40 AM
in response to: Peter Zheleznia...
|
|
|
>It appears they don't work because SynthBooleanTCR does not call super.
If you look in the JTable, you'll find there is BooleanRenderer,
static class BooleanRenderer extends JCheckBox implements TableCellRenderer, UIResource
and this has a getTableCellRendererComponent. But as you see from the definition of the BooleanRenderer, a super... does not make sense, cause the alternate-color is set ONLY in the DefaultTableCellRenderer. So, guess there is really some fun ahead to fix the class-structure properly :(((
|
|
|
|
|
|
|
|
|
Is Nimbus breaking Tables UI delegates contract
Posted:
Mar 23, 2009 4:18 AM
in response to: kleopatra
|
|
|
I've seen the nimbus alternate row striping conflict with the alternate row highlighter(s) in JXTable before. Should we consider basic row striping a function of the PLAF now?
Wondering how to handle this in SwingX (potentially any other 3rd party table libraries). Do I have to check if the active PLAF is nimbus and disable it's striping before installing my highlighters?
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 23, 2009 5:15 AM
in response to: osbald
|
|
|
Richard,
actually I don't yet completely understand what's happening with the striping - there seem to be different places where it is applied. Because, JXTable doesn't use core renderers, so the property set in the defaultTableCellRenderer trivially isn't used. Nevertheless, we get the striping with Nimbus as LAF - so the ui-painting somehow interfers under swingx' feet. Which is ... bad. And it does it in a funny way, swingx checkbox renderers have the "brighter" line as "darker". Much fun ahead :(((
CU
Jeanette
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 24, 2009 12:36 AM
in response to: kleopatra
|
|
|
I do not remember exactly how you / SwingX implemented the alternating rows, but I added it directly into my JTable extension, in the getCellRenderer method. That then does not conflict with any other renderers and it works finewith Nimbus. I do know that I had to disable the JXTable version.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 24, 2009 1:31 AM
in response to: osbald
|
|
|
swing@javadesktop.org wrote:
> I've seen the nimbus alternate row striping conflict with the alternate row highlighter(s) in JXTable before. Should we consider basic row striping a function of the PLAF now?
>
> Wondering how to handle this in SwingX (potentially any other 3rd party table libraries). Do I have to check if the active PLAF is nimbus and disable it's striping before installing my highlighters?
Ehmm.. Nimbus should be no different than GTK in this respect - is it?
So one possible way to detect LAF support for striping is to check
defaults table for "alternateRowColor". If it is defined then LAF should
be taking care of striping.
--
Peter
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 24, 2009 7:57 AM
in response to: Peter Zheleznia...
|
|
|
> Ehmm.. Nimbus should be no different than GTK in this respect - is it?
Are you saying this alternateRowColor striping was added for GTK LAF and not Nimbus? or just that GTK also has alternate row striping as a PLAF function? I've yet to see a user using Linux so don't really know if that also happens to be malfunctioning.
Substance also seems to see alternate row striping as part of the PLAF but it sensibly appears to disable it's striping on SwingX controls. Or maybe because it's striping isn't hacked into the JTable and/or delegates (?) so dosent effect SwingX renderers (which aren't based on the Swing default renderers).
With SwingX it looks like we'll have to detect Nimbus, then look for the alternate colors, then if highlighters are in use possibly disable Nimbus alternate row painting somehow (what is it overriding the renderers?) The SwingX highlighters which normally do the striping are much more flexible than simply every-other-row, so delegating to the Nimbus LAF is far from ideal.
Alternative is simply not to support Nimbus (esp. as Substance does a better job if you're into cross platform PLAFs).
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 3:05 AM
in response to: osbald
|
|
|
swing@javadesktop.org wrote:
>> Ehmm.. Nimbus should be no different than GTK in this respect - is it?
>
> Are you saying this alternateRowColor striping was added for GTK LAF and not Nimbus? or just that GTK also has alternate row striping as a PLAF function? I've yet to see a user using Linux so don't really know if that also happens to be malfunctioning.
alternateRowColor was added in Synth, so both GTK and Nimbus could use
it, but i've realized that GTK just doesn't.
And now this code is promoted to DefaultTCR, so any Swing LAF would have
striping once the alternateRowColor property is defined. Even Motif.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 4:22 AM
in response to: Peter Zheleznia...
|
|
|
>And now this code is promoted to DefaultTCR, so any Swing LAF would have
>striping once the alternateRowColor property is defined. Even Motif.
If so why do SwingX components get striping when they don't use DefaultTCR? appears as if the striping has been done at a higher level? ..which'd be a undocumented regression.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 26, 2009 12:33 AM
in response to: osbald
|
|
|
swing@javadesktop.org wrote:
>> And now this code is promoted to DefaultTCR, so any Swing LAF would have
>> striping once the alternateRowColor property is defined. Even Motif.
>
> If so why do SwingX components get striping when they don't use DefaultTCR? appears as if the striping has been done at a higher level? ..which'd be a undocumented regression.
Not sure. I've checked and it's only Synth/DefaultTCR that use
alternateRowColor.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 27, 2009 12:18 AM
in response to: Peter Zheleznia...
|
|
|
Oops, it seems i haven't really checked ^)
It may be that SynthTableUI.paintCell() interferes. It tries to set
alternate color on any renderer.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 3:10 AM
in response to: osbald
|
|
|
another problem is that Nimbus got the alternation different (wrong? don't have so many apps with striping - thunderbird and this forum overview): they color the first row with the alternate and leave the second to the normal background, that is they stripe the even rows. (hehe - the outcome of row % 2 <g>). SwingX stripes on odd rows. That combined with some opaqueness (?) weirdness on a checkbox lets a JXTable appear funny without highlighters and very dark if the default ui striping (as defined by HighlighterFactory.simpleStriping) is applied. For an example, see the RendererExperiments in my incubator.
Basically, our place to handle laf dependent striping is the HighlighterFactory and UIColorHighlighter: the options are
- add a never predicate if the LAF declares it's doing it, possible only if there _is_ public api to decide and the striping is working correctly bug-free. Anybody who wants to rely on undocumented per-component type or whatever hot-fixes can do so at any time <g>
- do the striping ourselves, but use the color provided by the laf. Looks funny due to the quirks above
- in applications, always do the striping with real alternateStriping (simpleStriping does nothing to even rows, so they are showing the normal background color), use default background for even and the alternate for odd. That looks okay, but ignores the individual target's color ..
still don't understand where that dark grey (with swingx simpleStriping applied under Nimbus) comes from ... our fallback is a light grey, how does it get dark?
Cheers
Jeanette
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 4:26 AM
in response to: kleopatra
|
|
|
> another problem is that Nimbus got the alternation different (wrong?)
It's quite fortunate did get it wrong or else the problems may not be apparent. When I first tried Nimbus I couldn't quite work out why everything looked grubby.. Until I realised it's darker grey alternate rows where mixing with my SwingX alternate rows..
Problem is most apparent in JXTreeTable where the Nimbus alternate striping appears in the hierarchy column.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 25, 2009 4:55 AM
in response to: kleopatra
|
|
|
> still don't understand where that dark grey (with swingx simpleStriping applied under
> Nimbus) comes from ... our fallback is a light grey, how does it get dark?
This is a common problem I have with LAFs the colors, fonts, margins, aligmnents etc.. theme information is increasingly well hidden in every LAF. PLAFs based on BasicLookandFeel invariably use its UIManager lookup keys "TextField.background" WindowPlaf using desktop SystemColors and frustratingly private XPStyle for xp/vista skins. While Metal/Ocean and Substance appear to have their own tweakable theme/skin implementations.
Nimbus has it's own sets of keys and client properties (BasicLookandFeel UIManagerlookups often fail with NPEs) the choices come from where? hardcoded gradients and painters? hidden DefaultLook class?
This makes life extremely hard for component/UI developers who are looking at building consistent looking applications. Should we have a shared API we could call to find the UIDefaults that'll work with all PLAFs? or is multi-PLAF support a fallacy and the developer should pick a single PLAF to support and stick with it, never offering users any LAF choices.. tend to think the latter at the moment, given all the problems (although system PLAF is an awkward choice as its several not one).
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Mar 26, 2009 12:47 AM
in response to: osbald
|
|
|
swing@javadesktop.org wrote:
> This is a common problem I have with LAFs the colors, fonts, margins, aligmnents etc.. theme information is increasingly well hidden in every LAF. PLAFs based on BasicLookandFeel invariably use its UIManager lookup keys "TextField.background" WindowPlaf using desktop SystemColors and frustratingly private XPStyle for xp/vista skins. While Metal/Ocean and Substance appear to have their own tweakable theme/skin implementations.
>
> Nimbus has it's own sets of keys and client properties (BasicLookandFeel UIManagerlookups often fail with NPEs) the choices come from where? hardcoded gradients and painters? hidden DefaultLook class?
Nimbus keeps many of its settings in UIDefaults, including painters. It
just may be that the property names differ from Basic, since they
include component state. Some colors are also taken from UIDefaults,
though many others are hardcoded in painters.
> This makes life extremely hard for component/UI developers who are looking at building consistent looking applications. Should we have a shared API we could call to find the UIDefaults that'll work with all PLAFs?
Having a common API is tempting indeed, but it may be that any API would
be eventually limiting LAF authors. Having a multitude of native systems
to support complicates things further. E.g. with GTK Swing doesn't even
know what a button will look like, which colors would it use etc. It
just passes the button to the native layer and get an image back. So if
we were to have a common-denominator API, it might not make much sense.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Apr 1, 2009 6:20 PM
in response to: Peter Zheleznia...
|
|
|
I think that when we talk about Look and Feel we shouldn't be talking in programming and APIs. We should talk in tools that could customize a base LAF to met your needs. The base LAF could be from scratch like Synth, from a glossy LAF like Nimbus or a something flat like Basic or MetalLookAndFeel. Perhaps you could choose a image based LAF or not.
Basically we need CSS and a LAF designer tool (like Nimbus designer) for Swing apps.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Apr 1, 2009 8:12 PM
in response to: hsfernandes
|
|
|
Just today i was having trouble using viewtooltips and Substance because of a similar problem (viewtooltips using background color for a and Substance animating it away). Tried to fix it myself, but code like this (using multiple mouse listeners for ex) is extremely difficult.
Did the smart thing and went to netbeans and copied the recent copy.
Almost fixed. Can't cope. Giving up on marginal improvement. Works on xp.
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Apr 1, 2009 8:21 PM
in response to: i30817
|
|
|
If you have Substance-specific questions, you're always welcome to ask in the project forums and mailing lists. If i don't know about a problem, chances are that it will go unaddressed.
Thanks
Kirill
|
|
|
|
|
|
|
|
|
Re: JTable-Zebra with one line ...
Posted:
Apr 2, 2009 12:51 PM
in response to: kirillcool
|
|
|
Its not so much a problem in your software, but the expectation Viewtooltips has of a fixed (selected)background/foreground color.
On the other hand i opened a issue for another color problem in your tracker today.
|
|
|
|
|
java.net RSS
