Screen crash if no user-input widgets are used and nav. buttons are pressed

[petrkr]

If there is only inform screen (without any widget which support user input) and some user input event is done (next/rev/inc/dec), then GUI will crash with div by zero

Task exception wasn't retrieved
future: <Task> coro= <generator object 'switchcheck' at 3f81dbd0>
Traceback (most recent call last):
  File "uasyncio/core.py", line 1, in run_until_complete
  File "/lib/gui/primitives/switch.py", line 38, in switchcheck
  File "/lib/gui/primitives/__init__.py", line 20, in launch
  File "/lib/gui/core/ugui.py", line 85, in _closure
  File "/lib/gui/core/ugui.py", line 232, in adjust
  File "/lib/gui/core/ugui.py", line 450, in do_adj
  File "/lib/gui/core/ugui.py", line 404, in move
ZeroDivisionError: divide by zero

class TestScreen(Screen):
    def __init__(self):
        super().__init__()
        wrilabel = CWriter(ssd, arial35, GREEN, BLACK)
        col = 5
        row = 40
        Label(wrilabel, row, col, 'Test')

Screen.change(TestScreen)

[petrkr]

For next/prev it is different exception

Task exception wasn't retrieved
future: <Task> coro= <generator object 'switchcheck' at 3f81b970>
Traceback (most recent call last):
  File "uasyncio/core.py", line 1, in run_until_complete
  File "/lib/gui/primitives/switch.py", line 38, in switchcheck
  File "/lib/gui/primitives/__init__.py", line 20, in launch
  File "/lib/gui/core/ugui.py", line 85, in _closure
  File "/lib/gui/core/ugui.py", line 214, in ctrl_move
  File "/lib/gui/core/ugui.py", line 403, in move
TypeError: unsupported types for __iadd__: 'NoneType', 'int'

[peterhinch]

A screen with no widgets is surely useless as there is no possible way to move to another screen or to respond to user actions. If you have no need to respond to user input I suggest you use nano-gui which is display only.

Unless you can convince me there is a conceivable use-case for such a screen, I don't think this is worth addressing.

[petrkr]

A screen with no widgets is surely useless as there is no possible way to move to another screen or to respond to user actions. If you have no need to respond to user input I suggest you use nano-gui which is display only.

Unless you can convince me there is a conceivable use-case for such a screen, I don't think this is worth addressing.

But I need some screens without user input (such as connecting to wifi) and some with user "confirm" button and later in app I will need some config menu.

If I will use nano-gui then I have to do every user-input by hand in program. That is why easier is use microgui and do some screens/windows without user inputs.

Or for example I will have other input (NFC, some relay) and I want to show only information like "I read NFC with ID 1234" do not need to user input for that (and also I do not want). It must be simple to users, not to confirm every window even it's only inform window

[petrkr]

this is example workflow for App like ATM with coin acceptor

[peterhinch]

OK, I see what you're trying to do: pop up a modal window with a text message which appears while some activity is taking place, then disappears when the activity completes. At present this can't be done: the design assumes there will always be a widget with currency and which will accept input from the switches.

I'll give this some thought and try to come up with a solution - I think we'll need a new PopUp object. In the mean time I suggest you don't create windows without active widgets as they result in confusing behaviour.

As an aside, a "connecting to wifi" window may need a "cancel" button in case connection fails...

[petrkr]

first workflow by trying use this library... https://www.youtube.com/watch?v=xl9R9ZKsKrE

Mostly for that "confirm" DialogBoxes sometimes would be handy to support PopUp it from Window, but I can not, because can not popup window from window...

Like in this workflow "Amount" screen is "Window" because I use "value", but handy will be on "OK" button say "Are you sure?" but this is also window

[peterhinch]

That looks very good. Nice design!

It is indeed not possible to open a Window from another Window. Enabling this would have added significant complexity, so in the interests of keeping things "micro" I disallowed it. You can, of course, overlay a Screen instance but this takes over the whole display until you go back.

The QR code generation is fast. I do recall the discussions from 3 years ago - the Python code has a lot of scope for optimisation and I was interested in doing this. But only as a collaboration with someone with a thorough grasp of the theory behind the code. Nobody seemed able even to specify how fast they needed it to run, so I dropped out of the conversation.

[petrkr]

I do not use Python implementation. It uses that native C++ one, that is why it's too fast.