Hi all, and thanks to everyone who’s taken the time to report issues and share feedback around Linux distribution. It’s clear that the current setup is causing frustration and we want to be transparent about how we got here, and what we’re doing next. Please excuse the long post.
tl;dr: We’re working on switching to classic confinement first, then adding a Flathub release. Input and help are welcome.
In March, we migrated from Ant to Gradle. This was a necessary step to reduce technical debt, improve the developer experience, and make it easier for others to contribute to Processing.
However, switching build systems meant we had to drop the old custom packaging scripts, which weren’t sustainable to maintain and didn’t align with how most Java software is distributed. From a technical perspective, this custom install process made future development much harder. From a user perspective, it led to a confusing experience on Linux, especially for people new to the platform, with downloads often just being unzipped and run in-place, without installation or integration into the system.
With the new Gradle-based build, we wanted to lean on existing packaging tools rather than rebuild the same ad-hoc setup from before. On Windows and macOS, this transition was smoother: we now offer signed .msi and .dmg installers with good integration into the OS. On Linux, things are more fragmented, and there’s no clear standard. We chose a packaging format that offered broad compatibility, automatic updates, and a streamlined release process. This is particularly helpful for users who aren’t experienced with Linux.
Snap’s containment features seemed like a good way to offer a more secure binary, so we initially opted in. In hindsight, that choice introduced more restrictions than expected for Processing’s typical use cases, particularly in education or when using serial devices, custom libraries, or sketches that expect full file access.
Changing how Processing is distributed on Linux wasn’t part of the original plan, and we definitely didn’t intend to introduce this kind of friction. Our main goal was to modernize the build system while keeping most of the user experience unchanged. Clearly, we got some things wrong, and we really appreciate your feedback.
Here is how we’re planning to address these issues:
-
Switch to classic confinement. This is the most straightforward way to address the regressions caused by the current sandboxing.
-
In parallel, we’ve also been working on a Flathub release. Having both Snap and Flathub available would help us support a wider range of Linux users.
We’d love your feedback on this approach: do you use Flathub? Would it be your preferred install method?
We’re not excluding the possibility of releasing an AppImage as well if there is interest in it. We looked into it earlier, and it seemed incompatible with our current build setup, but we’ll take another look and see if those issues can be addressed.
We know the current situation isn’t ideal, and we appreciate your patience while we work on making Processing easier to install and use across Linux distributions.
Side note: if you prefer an experience closer to how Processing was previously distributed, you can find portable builds on the GitHub releases page.
If you have ideas, packaging experience, or time to help test upcoming builds, please let us know. We’ve also made it much easier to build Processing from source for those who want to get hands-on with the codebase or contribute directly.
Thanks again for helping us make Processing better.
Cheers!
@stefterv & @sableraph