Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to extend customization TreeSignleStepDebugPainterin in xml #686

Open
xcfdszzr opened this issue Dec 9, 2021 · 3 comments
Open

How to extend customization TreeSignleStepDebugPainterin in xml #686

xcfdszzr opened this issue Dec 9, 2021 · 3 comments
Assignees
Labels
Projects

Comments

@xcfdszzr
Copy link

xcfdszzr commented Dec 9, 2021

image
image
image
image
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;
}
image

@mgarin mgarin self-assigned this Dec 9, 2021
@mgarin mgarin added the question label Dec 9, 2021
@mgarin mgarin added this to Styling in Questions Dec 9, 2021
@mgarin
Copy link
Owner

mgarin commented Dec 9, 2021

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>

@xcfdszzr
Copy link
Author

Dear author, can your next version have this detailed DEOMO? About Painter custom XML

@mgarin
Copy link
Owner

mgarin commented Dec 30, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Questions
Styling
Development

No branches or pull requests

2 participants