Editing Python Desk Top Applications
Jump to navigation
Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | This | + | This will be a page about how I write my desktop applications, and so naturally, how I would recommend they be writtern. It also documents the structure of most of the applications that I have documented on this wiki. Try them and let me know how you think they might be better. |
− | + | [[Python Smart Plug Technical]] | |
= Overview = | = Overview = | ||
== General Information == | == General Information == | ||
− | These notes are here so you can more easily modify my code and build your own. | + | These notes are here so you can more easily modify my code and build your own. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Here is an overview of the general plan, details can be filled out by reading the example code in my projects ( see category ..... below). | Here is an overview of the general plan, details can be filled out by reading the example code in my projects ( see category ..... below). | ||
+ | |||
The overall architecture is called the model view controller or MVC. | The overall architecture is called the model view controller or MVC. | ||
Line 45: | Line 29: | ||
*Windows 10 64bit | *Windows 10 64bit | ||
− | *Anaconda Spyder | + | *Anaconda Spyder 3.x |
*Python 3.7 | *Python 3.7 | ||
Line 59: | Line 43: | ||
I have had some issues with matplotlib in linux which are still unresolved. | I have had some issues with matplotlib in linux which are still unresolved. | ||
+ | = Components and Functions = | ||
== Imported Libraries == | == Imported Libraries == | ||
Frequently or occasionally used: | Frequently or occasionally used: | ||
Line 67: | Line 52: | ||
* SQLLite or MySQL for the database. | * SQLLite or MySQL for the database. | ||
* os, sys, psutil, platform .. and pathlib for system access. | * os, sys, psutil, platform .. and pathlib for system access. | ||
+ | |||
== My Components == | == My Components == | ||
Line 73: | Line 59: | ||
* Global Singleton for app cohesion. | * Global Singleton for app cohesion. | ||
* Parameter file for easy customization. | * Parameter file for easy customization. | ||
− | |||
− | |||
− | |||
− | == | + | ==== RunningOn ==== |
+ | A new class RunningOn has fairly recently be added to gather information about the platform the system is running on. This information is later used to adjust the system automatically to run when moved from system to system without any code or parameter changes. It is a bit tricky because some of the functions it uses and value obtained vary from system to system. Still seems to work pretty well. | ||
+ | |||
+ | Variables in RunningOn may be use in parameters to branch based OS or computer name or TCP IP address. Occasionally values will be used in other code. | ||
− | |||
− | + | ==== Paths and File Names ==== | |
+ | There are a couple of challenges with paths and file names: | ||
+ | *Are they relative or absolute? | ||
+ | *How to OS differences effect the code? | ||
− | My | + | My current approach: |
− | + | *For files that are "close" to the code, in your system for the application, I try to use file names that are relative to the installation location of the main Python application. To facilitate that the application tries to determine the startup location of the application and change the default directory to that location. Then notations like "./images/something.png" seem to work in the code. Since slashes seem to work in windows I try to avoid back-slashes. | |
− | |||
− | + | *For system resources, like your editor, I use both bare filenames -- the system can often find them through environmental paths, or full file names. These are mostly in parameters.py so you can use what works for you. | |
− | |||
− | |||
− | |||
− | |||
− | + | ==== Helper Tread ==== | |
− | |||
− | + | The application has a main thread running in a Tkinter mainloop. There is also a second thread called a "helper" running which makes some processing much easier. To make GUI mainloop responsive to both the GUI and its own processing it uses a pseudo event loop or a polling subroutine that is implemented in xxxxx. The frequency which polling occurs is set in parameters, the relatively low rate of 100 ms between calls ( .1 sec ) seems to give a perfectly responsive application in most cases. I have run it as fast as once every 10 ms. Have not tried to find a limit. | |
− | |||
− | + | === Database === | |
− | |||
− | |||
− | |||
− | |||
− | + | == The Controllers for Smart Plug == | |
− | |||
− | + | The class for the MVC controller is also the class you create to run the application: see the code at the bottom of the file, just run the file. Similar code is at the bottom of some of the other source files to make it convenient to run from those files, this is just to make it easier in development, the code in smart_plug.py is the model for what should be used. Sometimes the code at the bottom of other file may have code for testing objects in the file, it may not be maintained, may not work as intended. | |
− | + | The __init__ method is the initialization and "run" method for the application. Much of the code that would normally be in it has been moved to .restart which is used to restart the application when just the parameters have been changed. See the docstring there. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Threads == | == Threads == | ||
Line 139: | Line 102: | ||
=== HelperThread === | === HelperThread === | ||
− | + | Refers to similar but different program !! Will update for this program soon. | |
− | + | HelperThread in smart_terminal_helper.py This class provides the support for a second thread of execution that does not block the main thread being run by Tinker. I call the two threads the GUI Thread (gt) and the Helper Thread ( ht ). It can get confusing keeping track of which method is running in which thread, I sometimes annotate them with gt and ht. The helper thread is started by running HelperThread.run() which pretty much just runs a polling task in HelperThread.polling(). HelperThread.polling() is an infinite loop, it uses sleep to set the polling rate. When used with the green house processing module, it may call a function there that is its own infinite loop. There are a lot of details here, I should write some more about it. | |
− | |||
− | |||
− | |||
− | |||
== Parameters == | == Parameters == | ||
Line 165: | Line 124: | ||
== DataBase == | == DataBase == | ||
For databases I have used both SQLLite and versions of MySQL. See application for which one it uses. I may expand on this section later for now see the code. | For databases I have used both SQLLite and versions of MySQL. See application for which one it uses. I may expand on this section later for now see the code. | ||
+ | |||
+ | == Polling == | ||
+ | Both threads have method that perform polling for events often for items in their queue that may have been sent from the other thread. Info on a similar app in [[Python Smart Terminal Technical Details]]. | ||
== Logging == | == Logging == | ||
Line 191: | Line 153: | ||
− | [[Category:Python]] [[Category:Python Projects]] [[Category:SmartTerminal]][[Category:Python SmartPlug]] [[Category:Python Easy DB]] [[Category:ClipBoard | + | [[Category:Python]] [[Category:Python Projects]] [[Category:SmartTerminal]][[Category:Python SmartPlug]] [[Category:Python Easy DB]] [[Category:ClipBoard]] |