Sakura's Notes and Plans

Notes and Plans by Sakura

I am the sole author of this document, so I write largely in the first person. References to “I,” “me,” and “myself” refer to Sakura, the project’s lead developer. Codex was used to improve the technical sections of the document, though the ramblings section is entirely my words.

Current shortcomings

The project is close to feature-complete, and nearly all the core functionality I wanted to replicate has been implemented. Snapshot 0.10.0 therefore focuses less on adding features and more on refining state management, installation workflows, and the overall user experience.

Why are these not filed as issues in the Codeberg repository? I may create formal issues later, but as the only developer, I do not want to fill the issue tracker with early planning notes—especially while I typically address problems as I encounter them.

UI/UX progress and remaining work

The tool window

The largest tool-window problems were addressed during the 0.10.0 development cycle:

Completed: “Use a custom installation path” now defaults to disabled, allowing users to select a detected installation immediately.
Completed: Persisted Blender installations populate the selector when a project opens instead of requiring another scan.
Completed: Executable selection was compacted, and related launch controls were consolidated under Run and Debug.
Completed: The redundant target Blender version, API-stub update, and editable extension-repository controls were removed. Project creation remains responsible for selecting a Blender target and optionally installing matching API stubs.
Completed: Project Blender Manager now renders immutable configuration snapshots and sends changes through a dedicated controller, reducing UI/state desynchronization and recursive editor updates.

The tool window is now much closer to the workflow I intended. Further changes should be incremental usability improvements rather than another large reorganization.

The Settings Pane

The settings pane still needs consolidation. Blender Discovery and Blender Version Management both expose installation scanning, so one of those actions should be removed or the sections should be reorganized around clearer responsibilities.

The minimum Blender version should probably become an internal compatibility value rather than a user-facing setting. It should track the minimum version supported by Blender’s extension system or the oldest Blender release supported by the plugin. The current minimum remains Blender 4.2.

The managed-download controls also need to match their actual behavior. In particular, Perform post-install cleanup? is stored but not yet enforced, and the older download-cache size setting does not currently govern cache eviction.

Functional Issues

The core functionality I wanted—the run and debug configuration—is complete and operates as intended. Most of the runtime is adapted from Blender Development by Jacques Lucke for use in a PyCharm development environment.

Eventually, I would like to integrate the legacy pydev backend that PyCharm used for many years. This would allow the plugin to support older IDE versions, such as 2024 and 2025, instead of requiring PyCharm 2026.1 or newer. However, doing so would require a new pydev runtime and the necessary Kotlin backend, so it is currently a low priority.

Managed Blender installation is the largest remaining area that needs hardening:

Downloaded archives should be checked against Blender’s published checksums before extraction.
Each installation should use an isolated staging directory so concurrent installs or stale extracted files cannot interfere with one another.
Post-install archive cleanup and cache limits need to be implemented rather than only persisted as settings.
Live Blender integration and platform-specific ZIP, TAR, and DMG extraction need stronger automated or repeatable integration coverage.

Core changes that need to be made

The most important state-synchronization work is now complete. Application and project configuration publish immutable snapshots, Project Blender Manager observes both scopes through a tool-window-owned lifecycle, and detected installations are persisted in the shared application configuration. This gives the UI one consistent path for reading and updating state.

The next architectural work should focus on the managed-installation lifecycle rather than another broad state refactor. Download, verification, extraction, cleanup, installation discovery, and deletion should form one explicit workflow with clear cancellation and failure handling. The existing services can evolve toward that design incrementally without delaying smaller stability fixes.

For the next few snapshots, the primary focus should be stability and maintainability. The codebase remains somewhat fragmented and disorganized, but dedicated work on its stability and structure should prepare it for a version 1.0 release.

Sakura’s ramblings and reasonings.

July 23, 2026

I am seriously debating making a dedicated blog so I can write about my thoughts and ramblings instead of this page on the documentation, but that’s a future me issue.

After changing the way I work with Codex, it’s been a lot more enjoyable to work with the codebase. I started taking a more hands on approach to modifying the codebase which has helped me gain a better understanding of exactly what is going on, and after some work and using Codex as a learning guide, I’ve managed to rectify the majority of the key issues I was having with the codebase before. The state system I had before was terrible, and while the Toolwindow has been almost completely refactored with a cleaner structure and become more editable, the next snapshot will focus almost solely on the Application level settings pane and settings featured there, and maybe some extra work towards improving the Blender API stub implementation so that they are properly set up. After that, the last thing I want to re-implement from the earliest stage is proper Blender configuration sandboxing. This is a feature I feel is extremely useful to ensure that developers are working in a clean environment, free of any modifications they may have made or any extensions interfering with their work.

Overall, I am feeling much better about the future of this codebase, and probably will start finalizing some graphics this weekend for the project, and maybe, just maybe, setup that blog so I stop rambling here. One more thing I really should implement too is adding SHA256 certificates to the main website where users download the file, so that it’s more readily accessible instead of having to get them from the Codeberg repository.

July 22, 2026

The Desync between the different systems could easily be chalked up to AI issues, as the codebase is largely written by Codex, however that is not the sole reason. Throughout the development of this project, the codebase has been through 2 major iterations. The prior iteration (Snapshots 0.1.0 to 0.6.0) is just, abhorrent disasters, barely anything worked properly but proved that a project like this was possible. For 0.7.0 I started anew, with plans to try and write the majority of it by hand. The core functionality was strong, the initial version of the new project wizard worked wonders, and I even managed, with some assistance, to get Blender to launch. However quality started to slip when I stopped being the engineer and just started delegating everything to Codex. I’ve started to take a more hands on approach with codex, and even trying to write the code myself. However, it’s clear my inexperience with Kotlin and the Intellij API is the real bottleneck within the codebase, granted Intellij’s docs are absolutely atrocious, and often just throw you straight into a file somewhere in the Intellij Community repository, which more often than not is written in Java on the older Intellij Platform Gradle Plugin v1.

Because of this, I’ve stopped relying on the Intellij Docs and started using Codex a lot more, which, for the most part, is very helpful, especially for automating tasks which take forever (Including doc updates and minor yet tedious refactors), but can still produce some issues and of course. When I was using it via my Jetbrains AI Credits, was expensive. I recently switched to using a ChatGPT subscription, which has already proven to be beneficial as I have easily gotten more usage of Codex via that subscription than buying Top off tokens from Jetbrains. Unfortunately, these are only really worthwhile when using Junie since Junie doesn’t just gobble them up like me when I have a bag of gummy bears, but the quality and output, like those gummy bears, are often shoddy at best. However; that being said…the automation, mainly in regard to publishing, git commits, and changelogs, has been incredible.

Now that’s out of the way… here’s to good things, and the future of Blender Development for Pycharm is looking wonderful!