Last week was somewhat of a Spring Break/sick week. I don’t think I had COVID-19, but I wasn’t able to work. Starting work again after taking a week off was admittedly difficult, but it has been good to get back into the groove of my Senior Project!
I spent a lot of this past week trying to understand the XML parsing process – importing and using data from an XML file in a python script. After getting back online, I was looking through my script and realized that some of the commands that I was using didn’t make very much sense to me. While I could just let it go (it was working just fine, after all), I have somewhat of a problem with not understanding what’s going on in my work. So I went through a tutorial website online, starting basically from scratch with what XML is and different ways for Python to import it. I ended up changing the XML-parsing package that I was using (I switched from xml.dom.minidom to xml.etree.ElementTree). This was not a very challenging process in the end because I had already made a function that takes things from the XML file, so all I had to do was change the body of that function, and everything worked like usual. This new package also seems to make reaching into the XML file and grabbing specific attributes easier, which is nice.
Towards the end of the week, I started working on a development to my code that would make it even more skeletal and non-hard-coded. The background of this mini-project is that I need to tell my script what XML file I want to use and where to find it. Obviously, this is not something that you can just include inside the XML file. The solution that my onsite advisor supplied is to make the program callable from the Windows command prompt, and from there, you specify certain arguments. In this situation, the arguments would be the directory path to the XML file and the name of the XML file itself. While I have not gotten this to work reliably yet, the way that one would call it is by typing $ python workflowtable.py -path C:\Users\tommy.edelmann\Workflow\Batch -filename prodzip.xml. This would supply the program with the necessary information to import the XML file and do what it usually does.
One problem that I see with the GUI package that I have been using is that the color option on tables is very limited. In fact, it seems like for the time being, putting any color on the inside of a table is impossible. One can change the theme of the entire window, but even still, the table is blank white. I first looked into how to change the color of a specific element, but this isn’t possible because of the way tables take in their data. As I said last week, tables take indexes for input data, and there is no way to add color to a list element. It is like trying to recite numbers 1-5 out loud, but you want to say number 3 in green…
I then moved to trying to get alternating row colors for separation purposes. Sadly, I found this on the online manual: “The version of tkinter that is being supplied with the 3.7.3 and later versions of Python is known to have a problem with table colors. Basically, they don’t work. As a result, if you want to use the plain PySimpleGUI running on tkinter, you should be using 3.7.2 or less. 3.6 is the version PySimpleGUI has chosen as the recommended version for most users.” To see if this was true, I downloaded Python 3.6.0 and ran the same code. Alternating row colors worked, but the whole interface looks much more clunky than with Python 3.8. I am deciding to stick with 3.8.
Side Projects + future thinking
Aside from direct progress towards my product, I also worked for a little while to sharpen my Python skills. During the school year, my Physics and Engineering teacher Dr. Grove introduced the class to Project Euler, which is a reservoir of problems that get progressively harder. Apparently some of the highest problems have yet to be solved by anyone, ever. While I wasn’t able to make any (significant) computer science breakthroughs, I was satisfied because I was able to complete many more problems than I could in school when I was first starting.
I know that I keep saying I will get to use my GUI in a test environment “next week,” but I have not gotten to it. This is because I want to get rid of the big problems so that I can worry about smaller things when integrating with the customer’s system. I honestly think that once I finish the command prompt project, I will be able to try out the test environment. Come back soon to see if I end up getting to it!