Improvement to dependency functionality in settings-schema.json files

[klangman]

This is my proposal for improving the dependency functionality for the settings-schema.json files.

Currently dependency strings can only contain a single variable, like "key=1" or "!key". This drastically limits the ability to have complex widget revealing logic.

An example of complex revealing logic can be seen here.

"dependency" : "enable-panels-effects & enable-panel-unique-settings & component-selector=7 & enable-panels-override"

This was enabled in Blur Cinnamon by monkey patching the JSONSettingsRevealer functions to enable a feature set that this code change provides.

This change adds "and" and "or" operator support for the dependency strings following the logical order of operators ("and" before "or"). I believe this code maintains compatibility with the previous logic. My testing suggests that this is true, but I have not tested all Applets/Extensions/Desklets to ensure it is true.

There are other limitations that this change does NOT address, but we could consider, like:

1. The ability to handle "key vs key" comparisons (i.e. "key1=key2"). This would require some key identifier like %key% or $key in order to know if a value is meant to be interpreted as a key or a constant string. We could use the old logic when no key identifier character is found in the string, and new logic when one is found.

2. The ability to use round brackets to order the evaluation of the "and" and "or" operators. In many cases expressions can be rewritten without brackets to achieve the same logic, but some scenarios are impossible without brackets.

I believe that simply adding "and" and "or" operator support will make a meaningful improvement to the usefulness of dependencies.

I welcome any feedback or suggestions.

[anaximeno]

Hello, I've felt the need some times of a bit more complex behavior in that sense indeed. I'll give my two cents about some of the points:

1. The ability to handle "key vs key" comparisons (i.e. "key1=key2"). This would require some key identifier like %key% or $key in order to know if a value is meant to be interpreted as a key or a constant string. We could use the old logic when no key identifier character is found in the string, and new logic when one is found.

Here I think scaping would be a better way (or an additional way at least) if an identifier is chosen (e.g. %key for using a defined key-value, and \%key for text), because the suggested adaptable logic could introduce some ambiguity or confusion in the behavior.

2. The ability to use round brackets to order the evaluation of the "and" and "or" operators. In many cases expressions can be rewritten without brackets to achieve the same logic, but some scenarios are impossible without brackets.

For what I remember from my studies in theory of computation and compiler development brackets can "easily" be handled using a pushdown automata strategy, using a stack and pushing to it whenever with find an open bracket, and popping from it when we find a closing bracket.

Anyway, this should be a nice improvement in my view, for xlets devs.

[klangman]

Here I think scaping would be a better way (or an additional way at least) if an identifier is chosen (e.g. %key for using a defined key-value, and %key for text), because the suggested adaptable logic could introduce some ambiguity or confusion in the behavior.

We could assume that the left and side is always a key, and only interpret the right hand side as a key if it has the appropriate identifier. This would allow for backwards compatibility but it would be confusing if someone decided to mix identified keys and assumed keys. (i.e key1 = %key2%). Also would prevent constants on the left (i.e 1 = key). Another possibility is to use a different key to define the dependency, i.e. When "dependency" is defined then the current logic applies. But if a "dependencies" is defined then identified keys are required.

"dependency": "key = const"
"dependencies": "%key1% = const & %key2% = %key3% & const = %key4%"

For what I remember from my studies in theory of computation and compiler development brackets can "easily" be handled using a pushdown automata strategy, using a stack and pushing to it whenever with find an open bracket, and popping from it when we find a closing bracket.

Yes, brackets would not be so difficult to implement, and there is a well known approach within compiler frontends. But it's still an extra chunk of code, for a feature that is unlikely to get much if any use.