What high-level problem are you trying to solve?
When I design a form with a default image that is loaded to the widget for annotation, it is possible for the enumerator to accidentally replace the default image if they are not paying attention.
They then need to discard the submission and start again or potentially don't realise what they've done and submit bad data. (This is not theoretical, it is happening to me and all I can do currently is put big red warning notes in the label)
Stretch: If someone is annotating and saves it, but realises they made a bad annotation, could there be a 'reload' button that could force the dynamic image to be reloaded to start again?
Any ideas on how ODK could help you solve it?
If the 'Take Picture' and 'Choose Image' buttons were suppressed, and the only option was to annotate the image, then this error would be prevented.
This would be an appearance for the widget, similar to annotate, eg no-capture, no-choose would each suppress one button so the appearance value would be annotate no-capture no-choose, or a single annotate_default to apply all three flags.
I think this is possible and perhaps not that difficult (‽) as currently annotate is an appearance that "unsuppresses" a button, and there was recent discussion about changing visible buttons for sound recording:
Thanks so much for sharing. This makes a lot of sense to me. If the user goal is to annotate the image, not 'Take Picture' and 'Choose Image' then hiding those buttons sounds like a good solution.
Beyond removing 'take picture' and 'choose image' buttons, an additional button for this workflow that would be helpful for the use of default images would be a 'reset' (probably then with an 'Are you sure?' popup!), so that if the default had been annotated and saved but was in error, the default could be reloaded back in.
Currently in this case the submission needs to be trashed and restarted to reset the default, or adding a question that is only relevant when the image field is not jr://images/... and using it as a trigger to recalculate the default image in again.
Interesting idea! It's certainly not ideal to reload the default image this way, but at least there is a way to do it. How frequently do people need to reset default images?
I am also curious to hear from others who might have a similar need for resetting default images in their workflow.
It happens reasonably often - if they muck up the annotation and have saved it, there's no way to restore to the original, and if they accidentally 'take picture' and replace the default that is supposed to be annotated.
I tried various methods to trigger the default but as a trigger can't be an or expression they have to change some selections back and forth, which will also have other effects on already answered questions.
I see there's an issue for hiding take/choose, so one cause of needing a reset (taking a photo) will hopefully soon be avoidable.
Yes and no... The manner in which triggers are defined in XLSForm means that no, you cannot have a dependent question being 'triggered' by anything other than a change in a single so-called antecedent question [aside, I discuss this limitation, albeit in a difference context, in some detail here: Spec proposal: expose xforms-value-changed event with odk:setgeopoint action in XLSForm]. Which is to say, Question B can only be 'triggered' by a change in Question A, not as you say a change in Question A or C.
However, under the covers in raw XForms, there is actually nothing to prevent you performing multiplexforms-value-changed event triggered setvalue actions - which is bascially what an XLSForm trigger becomes - to accomplish this. That is, you can actually have Question B be recalculated whenever Question A changes or when Question C changes (in fact they can even perform completely different calculations!)
Have a play with this XForm. It essentially consists of two different types of multi-triggers. The first triggers the same calculation whenever either of two antecedent questions change; basically your "trigger can't be an or expression" situation. The second set is a min/max example that readjusts a previously entered value should the min or max then be adjusted.
I'm not 100% sure of your specific usecase around restoring original images, but - at least in terms of being able to have an or expression of some form as a trigger - perhaps this could be helpful?
Thanks as always for the detailed explanation. I should have said 'an XLSForm trigger can't be an or expression' as @LN has previously explained this to me. In practice, I'm not directly authoring XForms or converting and editing XML, so for all intents and purposes, to me today, triggers can only practically be single values.
