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
# 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.
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.
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).
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/BrickPi3Scratch.py) 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)