Condition returns true, but style is not applied?! Cause of confusion ?

[Robert STeiner]

Please see attached video. The map will follow in the post below

I understand that chaining conditions is not possoible/intended at the moment, because problems like loops could occur. However, the condition editor gives the user a different impression. The selected condition in the video shows, that the result is true, even if it relies on another condition. The user would expect that freeplane applies the style to the node.

[quickfold]

I looked at the video and the map. You said that you expected the icon to appear because the style Nodetype.Measure was explicitly applied. But the definition of that style in the Style Editor does not include an icon. The style Anchor Measure includes the ruler icon. So I am not clear on why you expect the icon to appear when applying the style Nodetype.Measure.

I think you are getting confused by the Format Panel 'Revert' arrow icon, which is something we are working on improving. The presence of the 'Revert' arrow icon does not mean that the style is explicitly assigned. What it actually means is that, for the selected node, there have been some manual changes to the node formatting so that the node does not fully match the style that has been assigned to it. Please let me know if this clears things up.

[Robert STeiner]

The second part surely clears up how I think about format assignments. :) Thanks :) And for the first part, please see video. You mean what I mean :)

[Dimitry Polivaev]

Please submit a bug report including the map used in the video so that I can follow the steps given in the video to reproduce the issue on my computer.

Posting an issue in the discussion forum is not helpful enough.
Sharing a video without the map is not helpful enough.

Regards.

[Robert STeiner]

the map :)

[Edo Frohlich]

I tried your example and couldn't find any error in your script.

only comment:
You can change the script filter from this:

node.getConnectorsIn().find { it.getSource().hasStyle('Nodetype.Measure')} != null

to this:

node.getConnectorsIn().any{ it.getSource().hasStyle('Nodetype.Measure')}    

[Edo Frohlich]

try using node.style.allActiveStyles

look here

[Edo Frohlich]

like this:

node.getConnectorsIn().any{ x -> x.source.style.allActiveStyles.contains('Nodetype.Measure')}

[Edo Frohlich]

new idea:

reorder your conditional formatting rules

[macmarrum]

I watched the video and looked at your map.
Thanks for sharing. I like the idea you're presenting.
This also gives me a change to learn something new :-)

The way I understand what you are trying to achieve is

Using the map-level conditional formatting, you want the node "Werbemaßnahmen terminieren" to have the style "Anchor.Measure" , when all of the following conditions are met:
1. The node itself has the style "Nodetype.Requirement"
2. The node has an incoming connector from a node with the style "Nodetype.Measure"

I guess what you are also saying is:

Filter Composer is claiming that the condition set is true (it shows a magenta bubble around "Werbemaßnahmen terminieren"), whereas the Map Conditional Style Engine is refusing to apply the style based on that condition set.

Please note that condition 1 makes the whole thing logically flawed, i.e.:

set style "Anchor.Measure" if style is "Nodetype.Requirement"

This is because once "Anchor.Measure" is applied, condition 1 (style is "Nodetype.Requirement") is no longer true. I wonder how this is handled by Freeplane Java code, but I would assume the outcome would be an error in the category of circular-reference/endless-loop.

Taking this into consideration, by changing condition 1 to something else (e.g. contains icon 'bookmark'), the Conditional Styling should work. But it doesn't work for me.
In fact, when I define only condition 2 in the Conditional Style, it still doesn't work. It looks like using a style assigned by Conditional Style Engine, as input for another condition, doesn't work.

As a workaround, you can put all the conditions in your script filter, i.e. including the original condition which sets the style "Nodetype.Measure" to the node "Filemakeranpassung" (i.e. text exists and any ancestor's text is "Maßnahmen":

connectorsIn.any{def connectedNode=it.source; connectedNode.text && connectedNode.getPathToRoot().any{ancestor -> ancestor.text=='Maßnahmen'}}

[macmarrum]

I just realized that my statement about condition 1 making the whole thing logically flawed, is wrong.
A node can have several styles, e.g.
1. Conditional style
2. User-defined style
3. Auto-level style
4. default

I also realized that the main point @sourceesoul is making is

Filter Composer is misleading the User, claiming that the condition is true (it shows a magenta bubble around "Werbemaßnahmen terminieren"), whereas the Map Conditional Style Engine is refusing to apply the style, because the condition relies on another condition (#3026)

I fully agree. It is misleading.

[macmarrum]

Hi Robert (@sourceesoul)

I had a thought about how to work around the shortcoming "using a style assigned by Conditional Style Engine, as input for another condition, doesn't work".

The idea is to create a conditional-style rule that records the conditional style being applied in an attribute. Once I have it as an attribute, I can check its value from another conditional-style rule.

Please see the attached map. It uses the following Script Filter

def cs='Anchor.Measure'
def theCondition = (style.name == 'Nodetype.Requirement' && connectorsIn.any { it.source['condiStyle'] == 'Nodetype.Measure' })
def _canApplyTheConditionalStyle(node, String condiStyle, Boolean condition) {
    if (condition.is(true)) {
        node['condiStyle'] = condiStyle
        return true
    } else {
        if (node['condiStyle'] == condiStyle) {
            node['condiStyle'] = null
        }
        return false
    }
}
return _canApplyTheConditionalStyle(node, cs, theCondition)

The script can be reused for any rule. You just need to change cs and theCondition.
The difficulty is that the condition must be part of the Script Filter (using any other Filter Type won't work as expected).

I wonder if it would work in a bigger map.
The order of conditional-style rules might be important. Especially if more than one conditional style is applied to a node.

Looking forward to learning your thoughts about this.

Regards
Mac

[Dimitry Polivaev]

It looks like a bug.
However it was not reported as a bug.

Usually I keep track of all bug reports and fix them before producing a new version.
Afterwards I sometimes check automatic bug reports. It is a second priority.

If there are any important findings I create a new release or a new preview depending on the importance of the findings.

So currently I am releasing Freeplane 1.9.10.

I read forum posts only after all the above steps.
I can easily miss forum posts, overlook forum posts.
If you post your consideration into the forum it means that you want to discuss the issue with the community. You can certainly do it anytime.

However in you want me to fix any issues you found there is only one safe way, and it is creating of the bug report.

Regards,
Dimitry

[Robert STeiner]

Sure :) I am just clearing up before I report a bug.