winput does not get re-enabled after being disabled

[pmelanson]

Hi maintainers,

In my program, I disable and re-enable a couple winput fields during runtime. It starts out enabled (and the user can properly enter text), then I set winput.disabled = True and then winput.disabled = False, but the winput field cannot be made to enter text again. This is unexpected, as re-enabling the winput field should allow text to be entered again.

Also, re-enabling the field does change the element's styling, but does not remove disabled="disabled" on the HTML element. So it seems like the intent is for the field to be re-enabled, but it does not properly get re-enabled.

I was able to reproduce this with the following program:

from vpython import *
w = winput(bind=lambda box: print(box.text))  # At this point, the user can enter text
w.disabled = True  # At this point, the user cannot enter text
w.disabled = False  # At this point, the user cannot (but I think _should_ be able to) enter text

Is this a bug? If it is, and we agree on a fix (having w.disabled = False re-enable the HTML input field), I can investigate and make a pull request.

Thank you maintainers!

[BruceSherwood]

I modified your test program to be able to try it in GlowScript VPython as well as in VPython 7:

cone()
def get(ev):
    print(ev.text)

w = winput(bind=get, type='string')  # At this point, the user can enter text
scene.pause()
print('disable:')
w.disabled = True  # At this point, the user cannot enter text
scene.pause()
print('enable:')
w.disabled = False  # At this point, the user cannot (but I think _should_ be able to) enter text

This works correctly in GlowScript VPython but not in VPython 7. So yes, it's a bug in VPython 7.

[pmelanson]

Thank you for confirming Bruce, I appreciate it.

I'll look into making a fix.

[BruceSherwood]

It would be great if you can propose a fix. What's deeply puzzling is that VPython 7 and GlowScript VPython use the same GlowScript library to deal with the browser display and events, and I too will poke around to try to figure out what's wrong. Here is an overview of the software architecture:

https://vpython.org/contents/VPythonArchitecture.pdf

The GlowScript repository is here:

https://github.com/vpython/glowscript

In the docs folder, GlowScriptOverview.txt provides more details on the GlowScript architecture.

Here is information on how to run GlowScript VPython locally, which makes possible testing changes to the GlowScript library:

https://www.glowscript.org/docs/GlowScriptDocs/local.html

If you execute build_original_no_overload.py using Python 2.7, and change the statement "if True:" to "if False", you will generate into the ForInstalledPython folder an un-minified glow.min.js which can be copied to site-packages/vpython/vpython_libraries and tested by running your test in (say) idle or spyder. (Running in Jupyter notebook or Jupyterlab requires additional fiddling.)

Note that in site-packages/vpython/vpython_libraries it is glowcomm.html that is used by launchers such as idle or spyder; glowcomm.js is used with Jupyter notebook (and a modified version is used in Jupyterlab).

Placing console.log(....) statements in the GlowScript code, or in the JavaScript section of glowcomm.html can be useful in debugging. You may also need to put debugging statements into site-packages/vpython/vpython.py.

Bruce

[BruceSherwood]

I should add that at https://github.com/vpython/glowscript the winput-related code is in lib/glow/prmitives.js. Search for winput.

[pmelanson]

Ah, great, thanks Bruce. I had already found the places in code, but was having trouble debugging it. Your tips, especially generating unminified source, really helped.

So far, I've double-confirmed that the disabled javascript setter for cwinput does get called, but only the first time that the vpython.py setter for disabled is called. On subsequent calls of the vpython.py @disabled.setter property, there is no corresponding call for the disabled javascript setter that I can log. Also, it doesn't seem to matter whether the argument to the javascript disabled setter is true or false, it disables the winput in either case when it gets to the line $(attrs.jwinput).attr('disabled', attrs.disabled)

(As a side note, @disabled.setter is the appropriate property in vpython.py, and it's defined for class controls, and other controls like class button(controls) also exhibit the bug we're seeing here)

Hopefully this is useful, I'm still looking into this

[pmelanson]

Ok, I think I've found the root cause.

The line that disabled or un-disabled the input field was:

$(attrs.jwinput).attr('disabled', attrs.disabled)

in glow.min.js in cwinput. When vpython code set winput.disabled = False, a command was getting sent, but by the time it was serialized and deserialized and arrived in glow.min.js:cwinput, the above $(attrs.jwinput) line was called with an argument of either 0 or 1 for attrs.disabled. But in both cases, it would disable the input field.

To properly un-disable the input field, $(attrs.jwinput).attr('disabled', attrs.disabled) had to be called with a boolean value instead of 1 or 0 for attrs.disabled. And I checked that calling $(attrs.jwinput).attr('disabled', false) does in fact re-enable the input field.

At the end of the day, I added the following code snippet to glowcomm.html, in handle_attrs in the very last else block:

if (val == 0 || val == 1) {
    val = Boolean(val)
}

Basically casting val to a boolean value if it's deserialized as 1 or 0. So handle_attrs looks like:

function handle_attrs(dattrs) {
    for (var idattrs=0; idattrs<dattrs.length; idattrs++) {
        ...
        } else {
            ...
            } else {
                if (val == 0 || val == 1) {
                    val = Boolean(val)
                }
                obj[attr] = val
            }
        }
    }
}

Adding this janky type-cast allows vpython to disable and re-enable input fields. i.e. it fixes the problem!

I'm not familiar enough with javascript or glowscript to tell if this is the cleanest solution, but it's a solution.

I'm considering the above code as a fix, but I'm not sure if there's a way for glowcomm.html to discern whether a deserialized attr value from vpython is a boolean value instead of just an integer with a value of 0 or 1 (or even whether it matters).

[BruceSherwood]

I'm VERY impressed that you were able so quickly to find a solution to this subtle problem! Thank you! There isn't an easy way to distinguish in glowcomm.html between 1 and true, and between 0 and false, so I modified the code in the GlowScript file lib/glow/primitives.js, by making the widgets accept any of these values (1, 0, true, false). In this vpython-jupyter repository there is a revised glow.min.js that you can use to replace the copy you have. This fix will show up in the vpython module with the next release, which I expect to come quite soon. I hope you have an interest in making further contributions to VPython. If so, please email me at bruce.sherwood@gmail.com.

[pmelanson]

Thank you Bruce! I very much appreciate the kind words!

I do have an interest in making further contributions to VPython, but I'm about 70% of the way through a big project (which involves vpython as the frontend) that I'm trying to wrap up before I get busy. When I encounter issues (like the os._exit(0) issue from a couple months ago, and this one) I try to find the root cause, but I don't think I have time to add features just yet.

As soon as I have time, I'll swing by again and try to help out! Thank you so much Bruce!

[BruceSherwood]

If it's not secret, may I ask what is the nature of your project? I'm unfamiliar with the notion of VPython 7 being a "front end", terminology that I associate with a program running in a browser that communicates with a distant server ("back end"), not a local server.

[pmelanson]

Definitely not secret! It's a 2D spaceflight simulator, that I'm doing as a re-implementation of an older QBasic spaceflight simulator that a teacher from my high school made over his lunch breaks.

My project is most like a game with a GUI, and at the beginning of the project one of my collaborators made the decision of using VPython as a "graphical front end," in that sense of the word. So VPython plays the role of something that is usually played by, say, Pygame.

If you want to see some screenshots, feel free to take a look at the README.md of https://github.com/OCESS/orbitx specifically the Screens section. I just uploaded a new screenshot of the current GUI, powered by VPython:

Perhaps not the intended use for VPython, but it's there!

[BruceSherwood]

Cool! I think VPython's intended use is for anything for which it's useful.....

[pmelanson]

Commit 3fc9851 in release 7.5.1 fixes this, thank you! I appreciate your help.