Graphical User Interfaces (GUI)
RealFlow’s Python implementation provides a series of instructions to create your own windows with menus and options. These windows can be used to enter your own settings or leave default values. The settings are then passed to a script which is able to process these data and feed the formulas. The advantage is that you don’t have to change the script each time you want to alter one or more values, because everything can easily be done inside a custom tailored window.
To apply a customised window you have to follow some global methods and rules. Once you have understood the basic concepts, the creation process for GUIs and windows is always the same and should become routine with growing experience. One of these rules concerns data types. In “normal” scripts, RealFlow was always able to automatically detect the data type and there was no need to introduce them separately, like
int frames = 10 float friction = 0.005
With GUIs and windows the situation is completely different, because you have to specify the correct data type now, and then RealFlow will check the entered data for plausibility. The reason is that Python/RealFlow always expects particular data types for certain functions. It is simply not possible to fill a vector’s individual scalars with strings. Such kind of vector creation is invalid and directly leads to an error message. You can either enter integers or floating numbers – and that is it. A notation like this is not possible:
Vector.new("red", "orange", "blue")
RealFlow GUI’s are not only capable of opening a window, you can also create your own error messages and make use of file and node pickers. The most common application is definitely to enter custom values and this requires three steps:
- Setting up the GUI window with all input fields and the definition of various data types
- Transferring the data from the window to variables
- Assigning the variables
A GUI can be opened either from a batch script or a simulation events script. In the latter case the GUI can only be started at the beginning of a simulation, not during a running process.