I am old (therefore old school), I thought the best way forward with graphic elements (like the logo, icons and button graphics) would be nice and small .png files. Enter svg (vector vs. raster)... since I am yet unaware of the display sizes, if I create vector graphics, they will have no noticeable compression artifacts at a wide range of sizes.

Of course, most of my graphics programs are raster based (krita5, apple proCreate) so that is where I shall begin my next part of the learning phase.

Also, going file to file and making sure each python file has a docstring (a comment beginning and ending with three ") that describes what the file does. This will help later as there are tools that can help create skeleton documentation by parsing docstrings. I remember Java having a similar mechanism.

But this division of work, first ensuring functionality, then worrying about how it looks, was the right move for sure. There is not any code that is confusing in there, and appearance is confined to the UI screens and their matched kv files, the logic is sound and not involved in the "look" aspect.

At this point, I should probably plan a way to back test the Markov chain distribution. That will not involve the gui, and instead remain in my script "lab" sandbox. I spent so much time getting things to work, but not enough time learning proper interpretation of the generated data.

That back test should probably answer the following questions...

1. At face value, how many times was the highest frequency follower a straight match for the game? (Will start with pick 3) as a simpler count, the first element of the distribution is the highest frequency, so did column1 match distOne[0] AND did column2 match distTwo[0] AND did column3 match distThree[0]?

2. As a total system, where did the matches come from most? I already know it is not the highest element most draws... so where in the dist list did they come from? Such as distOne[4] AND distTwo[3] and distThree[8]... building up a matrix of hit distribution.

3. What about lag potential? Did the highest frequency in the chain match somewhere over the next N draws? Now, maybe not, but since we are looking, may as well look everywhere.

Why this back test now? Because it is better to move forward then stare blankly at half finished ideas. Also, I feel that based on the data so far, this Markov chain strategy will be helpful with the vertical sum concept I am cooking up.

As for now, the priority is the app... after graphics creation and implementation, the app will be just about done. But I learned that if I put a next project in the back of my mind early, the solutions tend to start leaking through rather than starting from scratch.

Between the processing steps available in the app and the draw history update feature, this project is already worth the effort, even if it never wins a single draw because I have the opportunity to upskill from writing scripts to pro grade software frameworks. When I saw how fast this project came together because I followed industry best practices at the script level, continuing the same practices at the app level really solidify the concepts, and I would not be starting from just ideas when I branch out into something NOT related to the lottery.

On that point, lottery data, even though nothing ever truly works out, is a long time hobby and allowed me to power through the challenges because I was motivated... not so much with most of the "To Do List" tutorials out there.