During our tenure at Howest University of Applied Sciences, a colleague and I collaborated on server and client system providing useful data and infographics for Dungeons and Dragons. This initiative was part of our coursework in Advanced Programming and Mathematics. The aim of this project was to set up a server and client in Python, aimed at teaching core programming concepts such as multi-threading, caching and communication protocols.
The Project
During our coursework we familiarized ourselves with the simple GUI library TKinter many are familiar with. As I already had sufficient experience in other GUI toolings, we decided to instead opt to use PyQt, which provides a more robust ecosystem and customizable GUI. This provided us with a chance to broaden our skill set by mastering a new framework. My responsibilities for this project were focus on implementing the server backend, communication protocols, multithreading, a CLI and the GUI whilst my colleague focused on data processing, graph generation and client-side requests.
Multi-Threading within PyQT5
PyQt restricts GUI component modifications to the main thread. Consequently, we had to structure our project with the GUI running as the main thread and delegate the server communication tasks to subthreads. This separates GUI management from communication with the server, ensuring the GUI remains responsive when handling data exchanges with higher loads.
Since interaction with GUI is limited to the main thread, launching a seperate thread to receive data from a Queue won’t function out of the box. To address this issue, PyQt provides a solution: signals. Signals enable cross-thread interaction by emitting data. This allows communication with the GUI components after receiving or transmitting data through Queues. Alternatively, PyQt provides their own Multi-Threading implementation.
Dynamic Data Analysis
My colleague incorporated the capability for dynamic filtering of the D&D database. Clients completely control what and how data is filtered and may request graphs to be generated based on these configurations. Generated graphs are cached on the server-side to allow fast transmission of previously requested graphs. To accommodate these dynamic requests, I ensured the GUI elements allowed the client to request any filter combinations.
Command Line Interface
Throughout development we frequently encountered the necessity to debug communication channels between clients and the server. Additionally, the project required a logging system which provided live feedback. To address both these challenges I implemented a Command Line Interface (CLI). Whenever any action is taken by a client, both ends log said action in the CLI, along with any warnings or errors that may be thrown. The CLI also provided text-based communications with other active clients and moderators.