Open xcfdszzr opened 2 years ago
If you want to override the selection painter - you don't need to override the component or add any custom annotatons. You can just reference your custom painter in your custom tree style:
<style type="tree" id="custom-selection">
<painter>
<!-- Selection background painter -->
<selectionPainter class="package.path.to.TreeSignleStepDebugPainter">
<decorations>
<decoration opacity="0.75">
<WebShape round="0" />
<ColorBackground color="247,247,247" />
</decoration>
</decorations>
</selectionPainter>
</painter>
</style>
Contents of the <selectionPainter>
depend on what kind of painter implementation you've made. You can use decorations if you are extending AbstractDecorationPainter
or AbstractSectionDecorationPainter
. In your case you probably should extend AbstractSectionDecorationPainter
specifically if you want out-of-the-box support for decorations in XML and some other features.
Also note that you can avoid having to specify TreeSignleStepDebugPainter
package in XML if you alias it with:
@XStreamAlias( "TreeSignleStepDebugPainter" )
annotation and process that class via
XmlUtils.processAnnotations( TreeSignleStepDebugPainter.class );
If you do so, the example from above would look like this:
<style type="tree" id="custom-selection">
<painter>
<!-- Selection background painter -->
<selectionPainter class="TreeSignleStepDebugPainter">
<decorations>
<decoration opacity="0.75">
<WebShape round="0" />
<ColorBackground color="247,247,247" />
</decoration>
</decorations>
</selectionPainter>
</painter>
</style>
Dear author, can your next version have this detailed DEOMO? About Painter custom XML
Depending on what exactly you want to be in such demo - information might already exist in the styling introduction article: https://github.com/mgarin/weblaf/wiki/Styling-introduction I always recommend reading this first before diving into using WebLaF styling system.
I will definitely be expanding demo app over time, but I doubt that it will ever be enough to answer all the possible questions about the styling aspects of WebLaF. That being said, if you have a particular example in mind that could be useful - feel free to suggest one, I'll do my best to add it to either wiki or demo application.
Although "Painter custom XML" seems like a very abstract/broad topic. Can you elaborate?
In case I may cover the question, here is a bit of a broad info on styling/painters and XML -
In general - painter part of XML is nothing more than a representation of actual Painter
implementation class instance. You can always find a specific class in the code and find all settings you can specify in XML in that class.
Here is one example:
In the code I've posted above - <selectionPainter>
is simply a field defined in TreePainter
class:
(https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/laf/tree/TreePainter.java#L78)
/**
* Tree nodes selector painter.
* It can be provided to enable nodes multiselector.
*/
@DefaultPainter ( TreeSelectorPainter.class )
protected ITreeSelectorPainter selectorPainter;
From that source you can see that if custom painter class is not specified - it points at the default one.
If you go to the source of TreeSelectorPainter
(and painters it extends) you will find all the settings it can contain.
Although in this particular case with TreeSelectorPainter
- it doesn't contain almost any custom code and simply extends AbstractSectionDecorationPainter
which in its own turn also doesn't have any custom settings. But it extends AbstractDecorationPainter
and that's where all the decoration settings are stored:
(https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/painter/decoration/AbstractDecorationPainter.java#L81)
/**
* Available decorations.
* Each decoration provides a visual representation of specific component state.
*/
protected Decorations<C, D> decorations;
From here you can dive into Decorations
class and find that it stores an implicit list of IDecoration
implementation instances which in most cases are WebDecoration
class instances.
WebDecoration
class contains a few implicit lists of shapes, shadows, borders and backgrounds. It also extends ContentDecoration
class which contains implicit list of IContent
implementations. That class in its turn extends AbstractDecoration
which contains all the basic settings of decoration like states
, visible
or opacity
attributes etc.
There could be some exceptions to this XML<->Object relation with some classes having custom XStream converters defined, like ComponentStyle
class, which XML output had to be customized due to their structure complexity or use-case nuances, but converters are also defined in the class and can be backtracked in the source code.
TL;DR: You can always dig into the source code and quickly find out what settings are possible in the styling XML. Btw, same approach is applicable to the icon sets, dictionaries and other settings specified via XML in WebLaF.
This is important because it is nearly impossible to showcase all of the possible uses and combinations of the styling system as it's whole point is to allow as much customization as you can possibly have over the component visuals and you are basically free to do anything to the component via it's style, although it may still be limited to an extent for a few select components at this time which haven't been updated to fully support styling.
public class EditorTreePainter<C extends JTree, U extends WTreeUI, D extends IDecoration<C, D>> extends TreePainter<C, U, D> { @DefaultPainter(TreeSignleStepDebugPainter.class) protected ITreeSelectionPainter selectionPainter; }