nano_gui_simpletest demo raises an exception

[peterhinch]

[EDIT] It wasn't obvious to me that to run the demos I had to run micropython rather than CPython. However, correcting this I still had problems.

I had this outcome with nano_gui_simpletest:

>>> 
[adminpete@meerkat]: ~/mp
$ /mnt/qnap2/data/Projects/MicroPython/micropython/ports/unix/build-standard/micropython -i path.py
path.py:  Added ['lib', 'examples', 'fonts'] to sys.path.

MicroPython v1.23.0-preview.72.g4a2e510a8.dirty on 2024-02-04; linux [GCC 11.4.0] version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import nano_gui_simpletest
MPDisplay: can't import name Pin
MPDisplay: Trying SDL2Display...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "examples/nano_gui_simpletest.py", line 7, in <module>
ImportError: no module named 'gui.core.nanogui'
>>> 

The installer shell script does not appear to install nano-gui.

The micropython-touch active.py demo runs but does not respond to touch using the touchpad left button.

[bdbarnett]

Hello sir,

It's not lost on me that you are the first to comment since I posted my announcement. I am a very big fan of your work. I find your posts nearly every time I'm researching a MicroPython issue. It's pretty obvious I dug into your drivers a tremendous amount. I appreciate what you do for the community!

I had a couple issues, one with the mpdisplay._viper.py file left out of the .json installer and another with not calling .show() at the end of nano_gui_simpletest. Both are corrected now.

I have the installers installing your micropython-touch. Since it and nano-gui both live in a directory called gui, and because micropython-touch seems to have everything nano-gui has and more, I don't have it installing nano-gui. I kept the nano_gui_simpletest file for anyone who downloaded nano_gui on their own. If both can live in the same folder, I'll add nano-gui to the installers.

I think your package.json file for micropython-touch may be missing some files, and it is creating a touch directory at the root of the install folder.

I'll dig into the touch problem shortly. It likely is a problem in my hardware_setup.py. calculator.py and blackjack.py are working for me, so touch is working. I'll post what I find.

Thank you very much!

[bdbarnett]

Changing the display format from GS4_HMSB to RGB565 fixes the touch problem. I haven't discovered why yet, so I made that the default in hardware_setup.py, so it defaults to a working state. FYI, I tried GS8 format and touch did not work with it either.

[peterhinch]

I think your package.json file for micropython-touch may be missing some files, and it is creating a touch directory at the root of the install folder.

I think I should get rid of that file. If you read the setup doc I advocate cloning the micropython-touch repo and using mpreote mount as a "no installation" approach. This leads to touch/ and gui/ directories in the root, which is by design and is the assumption behind all my code. The mip installation was an idea to install an absolute bare minimum to run simple.py, but on reflection it's not very useful as it assumes ILI9341 hardware. The touch GUI is highly modular. Modifying package.json to install the whole GUI with all widgets, demos and device drivers is probably excessive.

The designs of micropython-touch and nano-gui are very different: nanogui.py comprises 110LOC and is entirely synchronous while tgui.py is 568LOC and asynchronous. Please don't assume any compatibility between them (by contrast micropython-touch and micropython-micro-gui are closely related). The widgets for nanogui.py and those for micropython-touch also differ.

I guess there is no reason why nanogui.py and tgui.py should not coexist in a gui/ directory but you may need to experiment with a shared installation: I have never done this and I think there are likely to be name conflicts with widgets.

[bdbarnett]

That makes sense. I removed micropython-touch from my mip installer, but it still get's cloned and copied with the bash and powershell installers. I made note of this in the README.md as well.

When I started this project, you hadn't released micropython-touch, so I was targeting nano-gui and micro-gui. There isn't a simple way to connect MPDisplay's event/device code for encoders to micro-gui like there is with touch drivers and micropython-touch, which is why I don't mention it much in the documentation. MPDisplay works with the display side of micro-gui.

By the way, did you try the mpdisplay_encoder_test? On my desktop with a mouse, the scroll wheel shows up as one encoder. On my laptop with a touchpad, two-finger swiping up and down shows up as one encoder, and left to right shows up as a second encoder. That should be very handy for developing an app with 2 encoders and transferring it to a microcontroller later.

[peterhinch]

Re encoder, I suspect the response of laptops to two finger swipes may vary. On mine (running Ubuntu 22.04.3) the left swipe shows a varying yellow bar but vertical brings another application to the foreground.

The behaviour of the calculator is very odd, with buttons appearing and disappearing as I click on them or on the places where they ought to be. A screenshot would be useless as the picture keeps changing.

I can imagine that supporting mcro-gui is difficult because it caters for a wide range of input configurations - there are a number of combinations of buttons, with or without an encoder, which may be used.

My gut feeling is that this needs more testing, perhaps on a variety of machines and OS versions.

[bdbarnett]

I appreciate the feedback. That's good to know about scrolling. I shouldn't assume anyone will be able to emulate more than one encoder using only their touchpad.

You are correct, it needs much more testing. I have only tested on MicroPython and CircuitPython on ESP32 series and RP2040, and also on CPython on WSL, Windows and ChromeOS, as well as MicroPython on WSL. I have not tested on a "natively installed (?)" Linux (not under Windows or ChromeOS) nor MacOS. I'm going to have to rely on feedback from the community for those.

I had similar (although I don't remember it being exactly the same) issues as you're having on my ChromeBook. It's as if somehow the screen refreshes are out of order. That doesn't happen under WSL or Windows, so I had chalked it up as a ChromeBook issue that I'd circle back to later. I have worked around it temporarily by setting the environment variable MPDisplay=PGDisplay to force it to use the PyGame implementation of the display instead of the SDL2 implementation. The other 2 display types, BusDisplay and FBDisplay, haven't exhibited any of those issues, so I'll dig into the problem with SDL2 next.

If you get the opportunity and don't mind doing it for me, will you please run the command

export MPDisplay=PGDisplay

and then try calculator.py on CPython on your laptop and let me know if it still exhibits the odd behavior?

Thank you very much!

[peterhinch]

That threw a Pygame exception and crashed my machine :(

I am not prepared to risk testing this further. Sorry.

[bdbarnett]

I'm very sorry to have wasted your time. I appreciate you trying it and appreciate everything you've done for me and the rest of the community.

---

From: Peter Hinch @.> Sent: Friday, June 14, 2024 12:48 PM To: bdbarnett/mpdisplay @.> Cc: Brad Barnett @.>; Comment @.> Subject: Re: [bdbarnett/mpdisplay] nano_gui_simpletest demo raises an exception (Issue #10)

That threw a Pygame exception and crashed my machine :(

I am not prepared to risk testing this further. Sorry.

— Reply to this email directly, view it on GitHubhttps://github.com/bdbarnett/mpdisplay/issues/10#issuecomment-2168494673, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6O73QU4RAU6VFX4WRKBN23ZHMUGBAVCNFSM6AAAAABJGAHHM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYGQ4TINRXGM. You are receiving this because you commented.Message ID: @.***>

[peterhinch]

I suggest you put a warning in the readme. Crashing machines that are in use is not a route to popularity. But there are ways of testing safely if people are aware that it is alpha code (VM's, live Linux disks etc).

That said, this is an interesting application with considerable potential. I think a lot of work is needed to make it reliable on a variety of computer platforms. Good luck with it.

[bdbarnett]

Yes sir. I have heeded your suggestion and add that warning to the top of the README now.

For what it's worth, I have corrected the issue with SDLDisplay randomly showing parts of the screen, such as in calculator, and have corrected the issue with PGDisplay crashing. I installed the latest Raspberry Pi OS on an old Raspberry Pi 3 I had and was able to duplicate what you were seeing.

The former was caused by my method of splitting the buffer into 4 parts to facilitate scrolling the display the way LCD displays do, but for some reason the issue wasn't surfacing on my Windows and WSL tests. I can't say why it was happening, but my initial tests show that it is fixed now.

The latter problem was that I am using a function in PyGame called pygame.transform.scale_by to scale the display, but that function was only added in recent versions of PyGame. I now check to see if scaling is set to anything except 1 in __init__, and if so, I check for the existence of that function. If it doesn't exist, I print a warning to the console and reset scaling to 1.

I appreciate the encouraging words. My ambitions for the project have grown in the 8 months I've worked on it. My ultimate goal now is to see manufacturers like Waveshare and Lilygo provide board_config.py's and MicroPython examples for their all-in-one microcontrollers with displays like they do for C and Arduino. They usually say their boards support MicroPython, but don't usually provide display examples for MicroPython. I'm going to need to drum up a tremendous amount of interest and support from the community before that happens.