I should be able to create a tri-state control to manage Sets

(User Story, Investigate , Priority: High, Test Status: No automated tests yet , Reported By Bad Link: Thing 3y285jl not found, )
Summary: This is specifically for the Arisia Space: the "I want this" and "I don't want this" sets should have a single tri-state Yes/Maybe/No controlling them.
This isn't critical, but is strongly desired by Anna.
The thing that has been bugging me about this request is that it's so specific. I don't have a good way to allow external JavaScript in (due to security), but I don't want to add every precise control people can imagine.
But the right solution is probably to provide enough power to build this control in QL itself. Here's a rough plan:
  • This is essentially a fancy radio button.
  • Bootstrap provides it (we're using it for Optional YesNoType already).
  • Therefore, it can be displayed already.
  • We could add _QLRadioButtons() as a new command, similar to _QLButton() -- that would be Querkish.
  • In there, we can provide a list of the buttons to display. To make this ideal, we should be able to render the button pretty precisely. (Ideally, I'd like a green checkmark, a grey O, and a red X.)
  • These buttons are stateful. So we should allow the user to specify multiple QL expressions for each button: one for what to do when this button gets pressed, and one for when it stops being pressed. (Ideally, we would like to be more functional about this, providing a data relationship between the button state and a Thing/Property state, but that may be over-ambitious for now.)
  • In order to enable set manipulation, we probably need to enhance the _changeProperties() function. This currently takes a list of exact Property values to set. We should add the ability to say, for example, _changeProperties(My Set.add($foo)), where the .add is a syntactic kicker than means the obvious thing for Set-valued Properties. Similarly, .remove.
This is all very tentative, but seems like the right Querkish way to deal with this problem: provide enough power to actually build this control in Querki proper, and thereby enable lots more new functionality.