So last year, the process was entirely limited to the classifier output. Pick a line that had all neutral values, the highest when sorted.

This first pick (the match 6 line) was stitched together using the classification AND the follower output.

1. Run both scripts and split screen the output for each.

2. Instead of just picking the highest neutral line or the most frequent follower, find the number in each column that sits highest on BOTH lists.

3. Record result and play for the cycle.

Sometimes that number was not the highest neutral, nor was it the most frequent follower. In fact, 2 of the 6 numbers selected were classified as HOT. This part of the selection process will be refined throughout the year.

I may not even hold the same combo for the full cycle, but this start with the Match 6 gives me 4 weeks of GUI development time.

That is where the true purpose of the GUI project sits... it does not generate a pick, it gathers, processes and presents data. It is still on me to figure out how to interpret the output.

At the onset of the idea was to be able to generate this data quicker and easier than the process I had in place. This gave me the idea of making an automated draw history updater, which works! I go from the manual process of copy/paste updates on the games I play (at the time) to updating the histories of 14 different games in seconds with a button click. This part of the GUI is already wired and working! The next part was wanting to be able to view the output of either script, that is where I am working now... the screens are getting there with each coding session. But now it still requires the laptop.

With the android part of the puzzle, I will be able to generate and look at the data from anywhere, anytime with no laptop needed!

The end goal is also to keep the framework flexible, so that any new script that can generate a different data view can be added without difficulty, to both the windows app AND the android app. This is where time taken now will yield benefits in the future.

I have a true MVC (Model, View, Controller) framework, where the data and the back end scripts are separated from the UI layer, and intersect at the logic layer. When the app is fully functional, I can go back and tweak the UI components to make it look good without affecting the functionality. The difference between the chaos of scripts and the elegance of a well defined framework. Thanks to Kivy, I can leverage my skill with Python for all of it, no dabbling with other languages or some other framework with it's own learning curve and particular quirks... it is a clean sheet build that is being engineered, not just slapped together.

The process is surprisingly similar to android native development, where a screen is registered and enabled in Java (or Kotlin), but has a separate file to control the layout (kivy's own .kv files, similar to android XML layout files).

Because I chose the KivyMD path, this allows incorporating Google's Material Design UI elements, so I can go for more of a native android look and feel vs the more utility based standard Kivy elements. I have not even made images yet, that will be a mini project unto itself one day... a logo, an icon, button images... all things to learn and experience.

With how challenging this small project is, makes one really appreciate Todd's wizardry with creating, updating and managing the LP!