Implementing Desktop App in Python

Added by J. Simmons about 2 years ago

While researching the work we will need to do in the Python firmware for the CHIPPro based controller, I had a epiphany. We can solve the the portability issue with the desktop app by rewriting it in Python.

The current app is written in C#, and targets MS Windows, which has been a source of concern for us in terms of portability and maintainability. After considering what the desktop app has to do, I have become convinced Python offers everything we need to implement the desktop app plus offers portability and it is already part of our technology stack.

So, just what do we need to implement the desktop app? Working from the user's perspective down to the Holoseat hardware, it must:

  1. live in the system tray/menu bar - check out pystray, a cross-platform Python library for building apps which reside in the system tray/menu bar
  2. provide a UI for managing Holoseat's configuration and defaults; preferably one that can switch between bootstrapping behavior over the Holoseat Serial Protocol and rendering the controller hosted web UI - enter PyWebView and Flask apps (in the desktop app and in the CHIPPro based controller)
  3. utilize the Holoseat Serial Protocol when the controller hosted web UI is unavailable - here is where the pySerial library comes into play, a cross platform serial communications library

Combine the libraries mentioned above with a cross-platform Python installer builder like .... and I think we have everything we need. What do you think?


Replies (1)

RE: Implementing Desktop App in Python - Added by J. Simmons about 2 years ago

We are moving forward with this plan. The first pass will be a minimum viable app for Windows. The capabilities required for the minimum viable app are:

  1. Read/Update the current configuration (enabled status, step length (1-4), forward character, reverse character)
  2. Read/Update/Reset the hardware defaults for Holoseat (enabled status, step length (1-4), forward character, reverse character)
  3. _Support interactive debugging via app hosted Serial Monitor - this is not strictly required, but it serves as a complete demo of current and future technology needs for the app making it a useful feature to implement early.

I have been reviewing material from Packt Publishing, including a video series called Mastering Flask and the examples use Bootstrap to speed up UI development. I am thinking I will develop the minimum viable app using Bootstrap. With that in mind, the layout for the app will be a series of tabs and a main menu.

Tabs

  • Controls: main UI, ultimately where one would select, but not define, a profile; it should update configuration live and stay in sync with updates to configuration live, e.g. enabled widget should update if the physical button is pressed. Each of the four settings will be their own form which submit on change. We will expand these forms later based on output type (mouse|keyboard) and to include running/sprinting, etc. These values can also be updated by API. Check out this thread for how to submit wtforms on change (https://stackoverflow.com/questions/38003712/how-to-pass-parameters-on-onchange-of-html-select-with-flask-wtf). Look at putting the forms into a div that can be reloaded (?) when values get updated from other sources (like the button). First implementation will use submit buttons on each form (instead of on change events), will skip fancy decorations (like buttons), and will not auto refresh (but reload will set values based on current configuration). Will duplicate these functions in rest API later.
  • About: lists version and licenses info for (on far right of Nav Bar)
    • Controller
    • Firmware
    • App
  • -- if debug --
  • Serial Monitor: app based clone of arduino serial monitor (on far right of Nav Bar)

Menu on far right (stacked horizontal bars)

  • Connect/disconnect: manage the serial connection (until we can work out auto-connect)
  • Hardware Defaults: Managing the defaults cannot be done over the API (so only implemented in wtforms). One form for the four (and only four) hardware defaults. Push them all down to controller in one command.
  • Help: (opens new window)
  • Close: closes the app window

(1-1/1)