ez.update() nomenclature

[vkichline]

With a screen manager, update() could refer to output as well as input.
For example, you could set the values of all your display controls, then call update() to display them.
Calling update() to read in the environmental state, but not actually change anything, may run exactly counter to users expectations.

A typical work loop consists of:

1. Read input
2. Process data
3. Update values
4. Draw the display

Currently, Core2ez calls step 1 ez.update() and step 4 ez.Screen.push().
That doesn't seem intuitive or symmetrical. Update() is often used in this sense in Arduino libraries, unfortunately, but that happened in a world where the display was Serial.print().

Actually, I see right now that the source code draws the screen first, then processes input.
I think it's best to leave these as two separate functions; don't conflate input and output; they are too different.

Perhaps:

ez.read();
... (do work)
ez.show();

Read, Input, Scan, Get could all be good verbs for #1.
Show, Put, Draw, Render, could all be good verbs for #4. And I direct ez.verb() to ez.Display.verb() in this context.

Just a suggestion. People are going to be approaching this from all kinds of backgrounds.

[ropg]

Nomenclature is hard, and I know it.

The problem with show() is that these are all widgets and the result of the last step isn't always that they are shown. The thing with update() is that it's very much an Arduino and an M5Stack thing, and people are used to having some update()s in their loop().

As an aside: I have plans to do away with the registering of events. We used that when we were waiting for something, so people could insert stuff there. The much more elegant and simple solution is just to call loop() whenever we need to wait, where people would insert stuff that they want to run all the time anyway. Also this business with returning the number of ms later you want to run again is nonsense: it makes it so that everyone must make functions that return stuff instead of using void() or whatever in loop(), and it's trivial for everyone that can return an int16_t to check that their stuff is not running too often.

(( Name for thing: 2ez ? (The generic name if it moves to other platforms? Sounds good: "Too Easy" :)

With 2ez, something that happens in the world can just pop another window over whereever they are doing by focus()ing it, and then if they blur() it the user is right back where she was.

I used push() because that's the sprite terminology that people already familiar with TFT_eSPI will know. I recognize there's multiple conflicting interests fighting here: I also want people to understand what is going on underneath and not create abstraction where just a different choice of words would keep them grounded in the underlying tech.

But yes, hard, all of it... Appreciate your thinking and there will definitely be opportunities to fix things, straighten them out and make things more logical. Right now I wanna get the gestures to work again. (They can be on any widget, so each screen can have its own gestures, or globally on ez widget.)

Then with scrolling widgets and gestures in place I can make the keyboard an integral part of it, and then make input elements that present the keyboard when you click. Then we need checkboxes and radiobuttons and we have a basic interface.

And then my plan is to create more events (E_FOCUS, E_BLUR and some sound events) and take a deep breath and a good look at te whole thing and fix what needs fixing to glue it all together. I have enough trust in the underlying foundation (DisplayZone, Widget) to think that that won't need any too major overhaul anymore. I love how essentially simple everything is underneath. It was fun coding this and finding that all this complex stuff I just knew as a user is actually not all that complex when you start coding it...

Do we know candidates that this would also run well on? Naturally we can port this back to the regular M5Stack and give it elements to do three-button things, but this shines on something with ESP-like limitations and touch or some other pointing device. Anything that cannot run Qt embedded, pref. using TFT_eSPI. I'm hoping they will make a a really cheap touch e-Ink device at some point, sized like a phone but also aimed at signage and such...

Anyway, that's some of my thinking. Please keep looking along with me and giving me ideas. I'd be happy to talk you through making some of your own widgets too, I think we're in that stage where I trust things to not too radically shift from one day to the next.

[vkichline]

@ropg, I think you have left out a category of widgets; light weight output controls.
In a small app, I just want to stuff values into objects to be displayed, and let the objects take care of formatting, decimal point alignment, etc. so I don't have to add a bunch of string formatting code. (Principle: ez)
There are two ways to go: a hierarchy of buffered widgets / text widgets / number widgets / floating point number widgets, or a single, internally complex display widget that can be set up for all kinds of formatting but is still easy to use.
At this point in development, I think the best approach is to try both. I will give them a shot.
Please let me know if you have any strong preferences or suggestions.

[ropg]

I think one that handles everything is the way to go, and that was where I was headed next.

I'm trying to mail you but you seem to not be reading the hotmail address. Can you mail me at rop -at~ rop.nl ?