Abstract
Flamenco is an open-source render farm web application created by the Blender Foundation. The target audience of Flamenco is small studios, typically consisting of artistic, non-technical users. To make the web application more user friendly, a settings page within the web application has been proposed to help users configure the application with ease. Users can manually edit the settings in a flamenco-manager.yaml, but with the addition of a settings page which provides input validation, presets, and descriptions, erroneous inputs are prevented and users get a better understanding of what each setting does. Additionally, features like multi-selection and mass job selection were proposed to speed up workflows by allowing users to perform actions on multiple jobs, tasks, and workers instead of one by one.
Summary
The primary goal of this project was to implement various features to make it easier for users to configure the Flamenco Manager and speed up workflow with job and task management. The secondary goal was to implement UI fixes and enhancements to improve the overall user experience with the web application. I contributed a total of 25 pull requests to Flamenco which include bug fixes and the implementation of the following features:
For more about my code contributions, see pull requests.
Design
For the settings page, I first designed a mockup of a form for users to input preferences in the form of text, numbers, and dropdown options. Because Flamenco has over 20 customizable settings, I settled on a minimalistic design and divided the amount of settings into five manageable categories: Core Settings, Timeout & Failures, Storage, MQTT, and Variables. Both the side dialog and subheader scroll along with the user’s screen, making it easy to access essential functions regardless of whether the user is at the top, middle, or bottom of the form.
The subheader acts as a navigation bar specific to this page, making it easy for users to jump to a specific section of the form. The subheader also contains the Save button, so that users can conveniently save their changes regardless of what scroll position they are at. Despite the fact that there are a lot of settings to tinker with, the sticky elements make it easy for users to jump around the form and find additional info without adding to the length of the page, minimizing the amount of time a user spends scrolling up and down a page.
Subheader navigation of Settings page
The side dialog provides a brief description about the page, along with a description explaining what each setting does. The description for each setting gets dynamically rendered based on which input the user is currently focused on, minimizing clutter and only showing what’s necessary based on where the user is clicking. By keeping the descriptions in the sidebar, text is minimized on the form, keeping it clean and making it easy for users to scan through.
Side dialog description when the input for port is focused
The Variables section was more complicated to design because users needed to be able to dynamically add variables, and have multiple configurations for each variable. Several iterations revealed that more attributes were required, like the audience. Users should be able to add/delete variables, and also add/edit/delete various configurations for each variable.
Mockup of Variables
Initial implementation of Variables
Final implementation of Variables
Designing multi-selection and mass job selection was straightforward since they function as extensions of already existing components. Multi-selection is a common feature across many applications like file explorers and IDEs, so I settled on conventional key combinations like Ctrl + Left-click to select a range and Shift + Left-click to select/deselect specific rows. With mass job selection (initially proposed as mass job deletion), users are given the choice of what action (delete, pause, cancel, or requeue) to perform after selecting the jobs. This feature is useful for managing large numbers of jobs, particularly when a user wants to clean up batches of old jobs.
Mockup of Mass job deletion
Process
For the settings page, I built individual Vue components for each input type equipped with input validation and error messages. To make the configuration data export and import properly, I implemented an API call for updating the flamenco-manager.yaml file on the disk, along with unit tests to ensure that the updated attributes on the form reflected the same attributes that were sent in the request body. The description of a setting onFocus is rendered on the side dialog. Additionally, I added these definitions to the Manager Configuration page of the Flamenco documentation, providing additional reading for those who want a deeper understanding of how Flamenco operates.
Final implementation of Settings page (1/3)
Final implementation of Settings page (2/3)
Final implementation of Settings page (3/3)
For multi-selection to work on the various tables, I added event listeners to detect key-click combos and used the Tabulator API to detect which row was being clicked. For Shift + Left-click, I calculate the range of rows to select based on the position of the clicked row and the active row; if there is no active row, the clicked row is the only one selected. Ctrl + Left-click will select or deselect a row based on its selected state. The Cmd key is also supported. Building on top of multi-selection, mass job selection was implemented by using the Tabulator API to search and select all jobs whose updated timestamp precedes the most recent updated timestamp.
Final implementation of Mass job selection
Results
Flamenco now has a working settings page, multi-selection, and mass job selection features. I submitted a total of 25 pull requests which have been merged into main. 3 issues were resolved by my pull requests, and I opened 3 issues of my own which will be left for future implementation, mainly because they are out of the scope of this project.Mentorship
Under the Google Summer of Code 2025 program, I received mentorship from Sybren Stüvel at the Blender Foundation. Despite the 12 hour time difference (I was in California, USA and Sybren was in Amsterdam, Netherlands), we had weekly meetings to discuss updates, timeline, and any blockers. I worked in 1-2 week sprints, submitted pull requests, made changes accordingly after reviews, and repeated this until the code was finally merged into main.Takeaways
Initially, I was hesitant to step outside of the javascript ecosystem. Writing API calls and unit tests in Go was daunting at first but opened my eyes to better ways of maintaining and architecting code. While gaining experience in new tools and a new language, I learned how to run tests using make in the CLI and in VSCode, how to use cURL and Postman to test API endpoints, and how to utilize Swagger documentation and OpenAPI to conveniently auto generate API code and documentation. I studied developer docs to better understand various go packages, including how to marshal/unmarshal with encoding/json, how to handle HTTP requests and responses with echo, and how to format durations with time. I also developed proficiency with error handling and learned about the data types Go has to offer. Overall, I gained valuable knowledge in the realm of Go, testing, and API’s.Huge thanks to the GSoC admin and Blender folks for organizing this program, and to my amazing mentor @sybren for his patience and guidance!