When is a widget property available to an iPython / Jupyter cell? - jupyter-notebook

I'm getting ready to create a communications widget for use in a Jupyter application. I'm trying to understand when the widget's "value" property can be accessed ... it looks like the "value" can be read anytime, but won't match the widget model "value" until cell execution stops (i.e., the widget's browser state isn't updated back to the widget's kernel state).
To test this, I tried creating a small slider widget, waiting for 10 seconds, and then reading the widget "value" property ... all in the same cell. In the 10 seconds, the user (i.e., me) has time to change the slider to something like "5".
Here's a small test that can be run in a cell. When the sleep() happens, I move the slider to value "5".
from ipywidgets import *
import time
slider = IntSlider(
value=7,
min=1,
max=10.0,
step=1,
description="Input:",
)
display(slider)
time.sleep(10) # move slider to 5
print("done " + str(slider.value))
I expected "done 5" but got "done 7", implying to me that "value" is updated only after the cell completes.
Is this always true? And is there a way to force synchronization between the widget's browser state and its state in the kernel?
(I do get the expected "done 5" if I move the print() to the following cell.)
Thanks!

There is basically at present no way to automatically force code running in a cell
to wait for an event or change in a widget. Things like time.sleep(3) will only
freeze the cell and a slider created in the same cell will not display until the
sleep is complete.
The user could create a slider in cell 1 and then execute a sleep in cell 2 and then adjust the slider and the code in cell 2 may see the change after the sleep
but in this case the synchronization is directed by the user and is not automatic.
You can also start Python code from a widget event, but the Python code does not "run in a cell" and the "prints" will not go to the standard cell output area but
the output can be captured in other ways,.
In the following screenshot I use the "Output" widget to capture output from a widget event
The basic problem is that all communication between widgets and kernels is via
one-way messages -- there are no "return values" or "acknowledgements" of any kind.
Please see https://github.com/AaronWatters/jp_proxy_widget/blob/master/notebooks/Tutorial.ipynb for more discussion.

As it turns out, there does seem to be a library that uses something like asyncio to achieve an inline wait. It's called jupyter-ui-poll at https://github.com/Kirill888/jupyter-ui-poll. The author says it's available on PyPI at https://pypi.org/project/jupyter-ui-poll/
Very promising! ... otherwise, I'm forced to agree with you.

Related

Raspberry PI GPIO Keyboard/Mouse Input

Trying to create very simple keyboard and mouse controller using the Raspberry Pi's GPIO pins. Would love to use the code in a educational setting, so trying to build super easy, readable code for children/students. But the code is acting somewhat strange, it keeps outputting the same keystrokes:
import gpiozero
from pynput.mouse import Button, Controller as MouseController
from pynput.keyboard import Key, Controller as KeyboardController
keyboard = KeyboardController()
mouse = MouseController()
Up = gpiozero.Button(26, bounce_time=0.02)
LeftMouse = gpiozero.Button(17, bounce_time=0.02)
while True:
if Up.is_pressed:
print("Up")
keyboard.press(Key.up)
Up.wait_for_release()
keyboard.release(Key.up)
elif LeftMouse.is_pressed:
print("Left Mouse button")
mouse.press(button.left)
LeftMouse.wait_for_release()
mouse.release(button.left)
Using Python 3.7.3. No matter which GPIO I trigger (26 or 17), the code always outputs 'Up' and press the keyboard 'up' button. It must be something stupid, but I can't seem to figure it out. Would love to keep using the if/elif, so I can expand the code later with more GPIO buttons. Any idea's anyone?
Although I am not very experienced in the GPIO of Raspberry, I think your code is almost alright. I suspected that the reason of always having 'Up' outcomes, which meant the 2nd mouse condition statement was bypass, was probably due to the word 'button' being not consistent with the module you called in the first line? Below is the one after using 'Button' throughout. Probably when you triggered pin 17, it did pass through the printing stage but it could not penetrate further. It will no choice but to select the first keyboard statement. So, it would end up with 'Up' all the way.
from pynput.mouse import Button, Controller as MouseController
elif LeftMouse.is_pressed:
print("Left Mouse button")
mouse.press(Button.left)
LeftMouse.wait_for_release()
mouse.release(Button.left)
I also found the below link quite useful in order to make sure the packages imported and defined properly.
pynput - Importing keyboard and mouse
Looking forward to hearing from your update.

How to escape from an update message?

I have following message in Progress-4GL:
DEF VAR L-temp AS CHARACTER.
MESSAGE "Give me information" UPDATE L-temp.
This shows an update message, which is fine, but when I try to escape from that message (e.g. I realise that I have clicked on the wrong button, launching this message), I can't hide that message:
How can I solve this (I simply want to remove the message from screen)?I can't add VIEW-AS ALERT-BOX as alert-boxes only can update logical variables and fields. Or is there a simple Show-Dialogbox() for such a case?
Edit
I tried replacing UPDATE by SET and viewing the whole thing as an alert-box, but this seems not to be allowed up (only logical variables and fields seem to be allowed).
Edit 2
Trying with PROMPT-FOR was not a good idea, because this seems to hide the rest of the window, while I want the message to be shown as some kind of a popup in top of the rest of my window/frame.
Edit 3
Also System-Dialog seems not to be a good idea, because all I want is to get a simple string.
It's a bit unfortunate that the 'close window' button does not by default, close the window. Even when a frame is defined as a modal dialog-box, the window-close event needs to be rerouted to close.
define frame frupdate
cinfo as char label "Give me information" with side-labels
with
title "Message Update"
view-as dialog-box
.
on "window-close" of frame frupdate
apply "close" to frame frupdate.
enable all with frame frupdate.
wait-for close of frame frupdate.

at selection-screen output VS on radiobutton group

I'm writting a report in which I have two radiobuttons of the group 'tab'. Depending on their value, I must set some screen fields to no-display, else, display them correctly.
I can make it work perfectly by using the event at selection-screen output. , but it refuses to work when using at selection-screen on radiobutton group tab -to test one, I comment out the other.
The code in both is exactly the same, so could someone help me understand the difference in the two events so I get why only one works?
events below, only the second one works.
at selection-screen on radiobutton group tab.
go_controller->modify_screen( ).
at selection-screen output.
go_controller->modify_screen( ).
They both call the same method
method modify_screen.
loop at screen.
case screen-group1.
when 'TAB'.
if use_otab = abap_false.
screen-invisible = 1.
screen-active = 0.
screen-input = 0.
p_int = abap_false.
p_nat = abap_false.
free p_table[].
else.
screen-active = 1.
screen-invisible = 0.
screen-input = 1.
endif.
modify screen.
endcase.
endloop.
endmethod.
Via debug, I see that both of the events are reached correctly, nevertheless, only the second one works.
Because it is designed like this: AT SELECTION-SCREEN ON... is a "process after input" (PAI) event. PAI is designed to react on user actions. At the end of PAI, the next dynpro is determined (even if it may be the same as the actual), and then the "process before output" (PBO) of the dynpro is processed. This is the preparation of the screen elements for the user. Only in PBO, the modification of the SCREEN table has an influence on the visibility or editability of the screen elements.
So, in reporting you are supposed to use at selection-screen output. to influence the visibility or editability of the parameters and select-options.

R Shiny How to indicate stale state when inputs have changed but score has not updated

I have a shiny app with many inputs & a scoring function. There is no action button per se. Any input change triggers a re-score.
Sometimes a user has changed the input but it takes the score some time to update. This may mislead the user in associating the new state with the old score.
I want to fix this by having some display cue e.g. a "Score is being computed" message or gray out UI etc. dynamically whenever the score shown is stale.
How do I achieve this? Any thoughts?
fn_run<-reactive({
scorer(inputs......)
})
output$score<-renderPrint(cat(fn_run()$score))
sidebarPanel(title="Scoring Outputs",width = 3,
h3(textOutput("title")),
h3(textOutput("score"),style="color:blue"),
)
Mostly the delay is discernible when I publish the app to shinyapps.io and not palpable on local shiny runs.
You can do this with some CSS and the shinyjs package.
The following blog has what I think you want:
http://deanattali.com/blog/advanced-shiny-tips/
The relevant code is found here:
https://github.com/daattali/advanced-shiny/blob/master/loading-screen/app.R
This will show you how to shade the whole screen whilst the app is loading.

catching change in spinbox - rtcltk

I'm creating a spinbox in R using rtcltk with:
from <- tkwidget(leftFrame, type="spinbox", from=0, to=0.1,
inc=0.001, textvariable=freqFrom,
command = function(){updatePlot()})
This works as intended (updatePlot is called) when I use the arrows of the spinbox, but does not work if I just type something in manually.
How do I catch the "value changed" event?
By default it does not change in this case in case you type in an illegle value (like deleting the last digit), or if the update is time consuming then you would not want it to update between every keystroke when typing in a 3 or 4 digit number.
You can add an update button than calls updatePlot when clicked so that the user would type in the number and when they know they are finished would click the button.
If you really want the update to occur with every keystroke then you can use the tkbind function to call updatePlot (something like tkbind(*spinbox*, "<Key>", updatePlot) where spinbox is the variable pointing to the spinbox).

Resources