Keyboard in Scratch not working over VNC

What is different in the way that Scratch is launched when going through the Dexter launcher? When using the Dexter launcher, the keyboard over VNC doesn’t work. However, if I launch the standard Scratch app on the Pi, the keyboard works (as it does in any other part of the os). Is there something special that the launcher is changing in the environment?

looks like it has something to do with the wxWidgets. Specifically once you create the wx.showModal() the keyboard input from VNC session is captured and will not relinquish until the python process exits.

Problem was solved by commenting the silly dialog box in ~/Dexter/lib/Dexter/Scratch_GUI/

#               dlg = wx.MessageDialog(self, 'This will close any open Scratch programs.  Please save and click Ok!', 'Alert!', wx.OK|wx.ICON_INFORMATION)
#               dlg.ShowModal()
#               dlg.Destroy()

If I get a chance I’ll dig into wxdigets. I was never really a fan tbh.

Hey @colin thanks for bringing this up! We will take a look.

ok. so the real root problem was that lxde was not configured properly on the supplied Dexter SD Card. Curiously, it seems that openbox wasn’t running by default:

pi@dex:~/Dexter/lib $ ps -ef|grep -i lxde
pi        1022   995  0 21:03 ?        00:00:02 /usr/bin/lxsession -s LXDE-pi -e LXDE
pi        1244  1235  0 21:03 ?        00:00:00 /usr/bin/lxsession -s LXDE-pi -e LXDE
pi        1446  1022  0 21:03 ?        00:00:43 lxpanel --profile LXDE-pi
pi        1447  1244  0 21:03 ?        00:00:11 lxpanel --profile LXDE-pi

So I removed and re-installed lxpanel:

sudo apt-get remove --purge lxpanel
sudo apt-get install lxpanel

A restart later and voila! openbox is now running. And voila, a completely different windowing experience!

pi@dex:~ $ ps -ef|grep -i lxde
pi         992   965  0 23:10 ?        00:00:00 /usr/bin/lxsession -s LXDE -e LXDE
pi        1216  1207  0 23:10 ?        00:00:00 /usr/bin/lxsession -s LXDE -e LXDE
pi        1366   992  0 23:10 ?        00:00:00 openbox --config-file /home/pi/.config/openbox/lxde-rc.xml
pi        1368  1216  0 23:10 ?        00:00:00 openbox --config-file /home/pi/.config/openbox/lxde-rc.xml
pi        1375   992  0 23:10 ?        00:00:02 lxpanel --profile LXDE
pi        1378  1216  0 23:10 ?        00:00:01 lxpanel --profile LXDE

Reverting my changes above and keyboard input continues to work.

I would emphasis I am running the supplied SDCard with Jessie (not Stretch) that came with the BrickPi starter kit. I suspect something is wrong with the production of the image and I would look into this.

Hello @colin

Thank you for reporting the issue and your attempts at solving it. I’ve tried duplicating your issue but it worked for me from the start. So I must be misunderstanding something.

Are you using a VNC viewer, or the VNC that is supplied to the browser?
If it’s a VNC viewer, which one is it?

I burned a fresh card from the image to ensure a clean starting point, and openbox is running just fine. I’m a bit mystified why it wouldn’t in your case.


to be clear. the keyboard & mouse worked via vnc. however, only when scratch was launched through the loader did the keyboard input stop working. close the launcher, and the keyboard input resumed. As I said, I believe this to be related to the window manager problem and this was tripped by the use of wx.MessageDialog . This has nothing to do with the vnc viewer (of which I did use them all).

Thanks @colin,
What do you call the launcher? This window?

I used the Scratch icon on the desktop, then ‘Start programming’ button on the above window.

Just trying to make sure I understand you.

yes. it was this window that spawns the bridge in the background
(~/Dexter/BrickPi3/Software/Scratch/ and then scratch
in the foreground.

my suspicion was that when the dialog was presented, stdin was polled for
confirmation but not released on .Destroy(). Then when the subprocesses are
exec, stdin is no longer available because the launcher python process is
still hijacking stdin. Again, replacing the window manager solved this

Also of note, is that the image on my SDCard was from June. I ended up
using the October image in the end and things are much smoother overall.
(though, it would be nice if that bridge service was not needed and was run
automatically - detecting what hardware is attached to the pi)