Zynthian GUI start up walkthrou'
The Zynthian GUI start process
It's important to consider quite what makes up the components of the zynthian system, because it isn't just one big blob of code that does everything. It's divided up into components that handle specific areas of concern. There is the GUI application that runs the GUI Screen handling and as a result probably provides the component that a user may identify most closely as the Zynthian.
The GUI screen in whatever form you may access it, be that on a zynthian itself or via a connected HDMI screen, a raspberry Pi 7" touchscreen, a 2.5" LCD screen or over a VNC connection on a browser, is a X-Window device generated by the Python TKinter module. From the zynthians perspective it doesn't care it just handles a X-Windows window which provides the interface.
This means that implementing mice and cursor's into this world is fairly simple and so the GUI can use a mouse simply connected to the Pi's USB port. The Zynthian has a setting to turn a cursor on & off for precisely this reason. The touchscreen is implemented this ways as well. This means that there are various display settings that allow font size and horizontal & vertical screen size to be defined. To cope with this wide range of displays. This has the side effect that screen characteristics need to be considered,so we avoid the cutesy pictures that seem to proliferate on many dedicated hardware devices that have only one screen size to consider. . . ( This is probably a personal gripe...:-) but it's helps to understand this limitation when proposing new features that would require GUI alterations or additions.
The starting point for any modern linux system is systemd and zynthian makes much use of thus infrastructure. Thus logging is best handled by using journalctl ( journalctl -fu zynthian will give a running report of service start up).
The entry point for the GUI that is managed by zynthian.service is the shell file
The Zynthian code entry point
This file defines a few functions
Configs from: source "$ZYNTHIAN_CONFIG_DIR/zynthian_envars.sh" source "$ZYNTHIAN_MY_DATA_DIR/midi-profiles/default.sh" source "$ZYNTHIAN_CONFIG_DIR/zynthian_custom_config.sh"
Now these are fairly low level functionality and try to helpfully display some information in case the GUI doesn't start for some reason, like machine IP address ( a well known bootstrap problem in that if you don't know the machine address how can you point a terminal at it to configure it with it's IP address...?). So that if your zynth doesnt start you can ssh into it to examine quite why start up has failed ( It's normally jackd whinging about something...:-) )
Once that load_config_env has loaded up all the environmental variables that hold the actual state of a zynthian. It's all in there and is used to define the context that the zynthian runs under. Quite how a specific environment file is exposed to this process depends on the config, so mechansisms like MIDI configs define these states depending on wether or not a user has defined their own specific MIDI configuration or indeed several. Zynthian is basically a device for starting and stopping jack instruments and interacting with the engines once they are running. The GUI controls those interactions.
We then start up the python file
This module primarily defines the zynthian_gui class object with a few tkinter helper functions and this is what actually handles all the GUI interaction and functionality.
It's about 2000 lines of code and after all this definition
At line 1775 or there abouts we get
- logging.info("STARTING ZYNTHIAN-UI ...")
Always good to log and use the python logging infrastructure.
Some name binding for maintaining different names spaces or some possibly more nefereous purpose, before running
This method of the zynthian_gui class configures the GUI environment ready to start.