It is interesting the conversation in the github discussion issue request for a real solution.
But twMat I think your solution is a real solution and does not necessarily need a core widget improvement, but it would be good, since this could be a common use feature.
I suppose the conversation could/should continue there in github, but I was wondering if a simple solution would be if the checkbox widgets checked and unchecked fields accepted filters that is they were treated as strings like currently unless they start with a “[” and if so first evaluate the filter to obtain the value. However the below may be a better solution. Because otherwise the two filters may need to match and I am not sure filters can handle the two purposes that checked and unchecked provide.
The trick is these fields are used for two purposes one is to test the other is to set the state. This is easily the same thing when a simple string toggle is in place, but not if we want to use listops to handle multiple values in a field.
Then I thought if the string is prefixed with either a + or a - this implies it is a list ops function. So if the checkbox widget encounters a string with one of these prefixing it it uses list ops instead.
The following could be applied to any field however it replicates manipulating tags.
<$checkbox field="tags" checked="+mytag" unchecked="-mytag" default=" -mytag"> Is it open?</$checkbox>
So if the +mytag was encountered the checked test would be [contains:tags[mytag]] and the unchecked [!contains:tags[mytag]]
and the reverse of the ± is reversed.
The action on click for each would be to provide the “signed value” to the listops subfilter.
We should however allow pseudo filters still to be passed eg; “+[[a tag/value with spaces]]” or “+[has[fieldname]then[client]else[friend]]” as long as they resolved to a string that can be given to the contains test and listops subfilter.
What do you think?
Perhaps I post it over there?