You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a home board with links to several sub-boards (e.g. "things") that do not vocalize their labels, but in the OBL that Coughdrop produces, clicks on those buttons are marked as "spoken": true.
I believe the problem is that:
activateButton doesn't initialize obj.spoken to false when it creates obj (here).
app_state.activate_button only sets obj.spoken in one place (here), to true; it is never set to false.
At some point, this log event gets uploaded, with "spoken" set to true if the button was spoken or unset entirely if it was unspoken.
Exporter.event_session sets "spoken" on the OBL event (here) to true if "spoken" on the log event is trueor if it is nil. (I'm not 100% confident, but I assume the unset "spoken" in the client-side log event translates to a nil"spoken" in the server-side log event.)
I'm not currently able to send a pull request to fix this (I'm waiting on my employer's copyright folks to get back to me), but my proposed fix would be:
Set obj.spoken explicitly in all cases in activate_button. This will ensure future logs are uploaded with "spoken" set properly to false for unspoken buttons events.
Remove the || event['button']['spoken'] == nil clause in Exporter.event_session. This will ensure past unspoken button events are not labelled as spoken in the OBL logs.
If the nil check was there because some older logs never have "spoken" included, I would assume that any session where "spoken" is never set is from that era, and force it to true only for those sessions.
spoken-unspoken.txt is a barebones subset of my OBL file demonstrating the issue; please compare the button events with "spoken": true to the utterance at the end.
Please let me know if I can provide any more information. I hope to be able to provide a fix at some point, if you'd like it, my employer's okay with me contributing, and my proposed solution is amenable.
Thanks for all your tireless work on Coughdrop; it has been a wonderful tool for me.
The text was updated successfully, but these errors were encountered:
juliatuttle
changed the title
Unspoken linked buttons logged as linked
Unspoken linked buttons included in OBL as spoken
Mar 27, 2022
I have a home board with links to several sub-boards (e.g. "things") that do not vocalize their labels, but in the OBL that Coughdrop produces, clicks on those buttons are marked as
"spoken": true
.I believe the problem is that:
activateButton
doesn't initializeobj.spoken
tofalse
when it createsobj
(here).app_state.activate_button
only setsobj.spoken
in one place (here), totrue
; it is never set tofalse
."spoken"
set totrue
if the button was spoken or unset entirely if it was unspoken.Exporter.event_session
sets"spoken"
on the OBL event (here) totrue
if"spoken"
on the log event istrue
or if it is nil. (I'm not 100% confident, but I assume the unset"spoken"
in the client-side log event translates to anil
"spoken"
in the server-side log event.)I'm not currently able to send a pull request to fix this (I'm waiting on my employer's copyright folks to get back to me), but my proposed fix would be:
obj.spoken
explicitly in all cases inactivate_button
. This will ensure future logs are uploaded with"spoken"
set properly tofalse
for unspoken buttons events.|| event['button']['spoken'] == nil
clause inExporter.event_session
. This will ensure past unspoken button events are not labelled as spoken in the OBL logs.nil
check was there because some older logs never have"spoken"
included, I would assume that any session where"spoken"
is never set is from that era, and force it totrue
only for those sessions.spoken-unspoken.txt is a barebones subset of my OBL file demonstrating the issue; please compare the button events with
"spoken": true
to the utterance at the end.Please let me know if I can provide any more information. I hope to be able to provide a fix at some point, if you'd like it, my employer's okay with me contributing, and my proposed solution is amenable.
Thanks for all your tireless work on Coughdrop; it has been a wonderful tool for me.
The text was updated successfully, but these errors were encountered: