Closed kirill-grouchnikov closed 6 years ago
In my application I have many Renderer inherit from SubstanceDefaultTableTableCellRenderer. For me it is of great importance to be allowed to return any JComponent here.
The preliminary plan (before I've looked into the specific details) is to follow the general outline of SubstanceDefaultRenderer classes. They override all paint methods and declare them as final, so that the app code cannot add its own custom painting logic. They also configure the foreground and the background of the content to be consistent with the highlights that are applied at the level of the container (JList, JTree, JTable).
So probably it will have some kind of an abstract method that the app code will need to implement to apply the foreground and the background to all the components inside the renderer hierarchy. The VisorMail app from substance-samples will be the main demo of this functionality.
The VisorMail app does not use default implementation of the renderer. In my case, I have to take care of it for tables that do not use a JLabel (JCheckBox) as renderer. The implementation of the interface TableCellRenderer with return of any JComponent is possible here. I hope I got it right? Maybe you can encapsulate the implementation here, so that the use is more comfortable.
VisorMail indeed does not use Substance-driven renderers. That was one of the main reasons for this feature request - to enable usage of more complex renderers while still retaining the Substance-powered highlight animations.
Will be tracked in kirill-grouchnikov/radiance#5
See http://www.pushing-pixels.org/2018/05/23/hello-radiance.html for context.
SubstanceDefault*Renderer classes extend the default classes and as such are limited to be extending the JLabel class.
See if Substance can provide an extension of JPanel that has built-in support for highlight animations for JList, JTable and JTree.