Preamble #

AeroThemePlasma is quite the slow burn of a project. I've been working on it for almost 7 years now, and when it comes to things like programming, project management and maintenance, it has served as a great learning experience. The scale of this project has grown past anything I could have predicted when I'd started it, sometimes leading me to believe I bit off more than I can chew. I'd like to go over some of the new changes that mark a transition for this project, elaborate on some of the decision-making, and talk about what's next for AeroThemePlasma.

Important changes #

Plasma 6.6 support #

To start off with the most cut and dried change: AeroThemePlasma now works on the Plasma 6.6 major release branch, and it will continue playing the catch-up game with upstream in order to brace for new changes across the board. This update might seem mundane, but ATP had lined up its share of significant updates with the release of Plasma 6.6 in order to more clearly indicate these big updates.

Repository cleanup and faux-rebrand to AeroShell #

The main repository of this project used to be a big, monolithic mess that just kept getting crowded with more components and subprojects, and while this was fine back when the project was much smaller in scale, the need to split the repository into several other smaller repositories has grown over time. It would be disingenuous of me to not admit that the main reason why the project was structured this way is because of my lack of experience with git when I first made the repository. It was clear that the project needed to be fragmented into several smaller repositories in order to deal with the increasing maintenance of the overall project.

The next logical step was to group all these new repositories together in order to enjoy all the benefits that repository groups provide. One benefit of having separate repositories is the ability to reuse the code in other projects, without code duplication and duplicated maintenance work. This would allow VistaThemePlasma to remove unnecessary code that can now be shared by both ATP and VTP, and it would allow VTP to join this new repository group so all of our work could be made more efficient.

AeroShell has been decided as the name for this software suite, with the name acting as an umbrella term for AeroThemePlasma, VistaThemePlasma, and all of the generic components required for both desktop experiences to work. The names AeroThemePlasma and VistaThemePlasma have stuck around for branding reasons, but more on naming and nomenclature later.

New installation methods #

AeroThemePlasma used to have a really unorthodox way of working on the user's system, which was simply not viable in the long run, causing confusion, errors, limitations, and messy home directories. For the longest time, AeroThemePlasma would exist in the user's home directory, meaning that multi-user installation was not a viable option unless you were willing to install ATP separately on every single user's home directory. It didn't help that there was an increasing amount of components which had to be installed system-wide anyway, so the general incoherence of it all was becoming unignorable.

The origin of this unorthodox installation method could be traced back all the way to the beginning of the project, when it really was mostly just a collection of themes for various components of the desktop (Plasma style, GTK theme, icons, sounds, and so on). The general notion for these simple, third party themes has always been to have the user install them to the appropriate paths within their home directory, and AeroThemePlasma followed suit, so this convention stuck around for way longer than it should have.

This is no longer the case, fortunately. Taking a page out of Plasma's playbook (and most other decently-sized C++ projects for that matter), AeroThemePlasma now also uses CMake for building and installing everything, which allows for configurability, respecting standard paths, being able to keep track of all the installed files, easier uninstallation, the list of benefits goes on and on. Automated builds with CI have been introduced along with this simplified build process (more on the CI later, perhaps in a future blogpost), providing prebuilt artifacts for those uninterested in compiling software by themselves.

No more manual tweaks

The new method of installation also no longer requires users to manually configure their system. ATP now handles this with default overrides using XDG_CONFIG_DIRS, and there is an Out of the Box application for settings that can't easily be integrated into this system.

Distro support

Lastly, as a result of all previously mentioned things, it is finally possible to install ATP with AUR packages! I'm a noob when it comes to writing and maintaining AUR packages, so feel free to roast me while suggesting fixes and improvements :^). I'm also working on ensuring that support for NixOS can be maintained. AeroThemePlasma also seems to work well on Fedora, although there hasn't been any work so far on creating packages for Fedora.

What's next #

Wayland support #

Knowing that Plasma 6.8 will drop X11 support entirely, AeroThemePlasma will follow suit. This means dropping all X11-related stuff in order to achieve Plasma 6.8 support. This will significantly reduce the maintenance burden of having to deal with two effectively different platforms, and will shift my focus onto fixing the issues that plague the Wayland session for AeroThemePlasma, improving the experience wherever possible. As someone who still uses X11 right now, and is not very fond of Wayland for various reasons, the Wayland session has admittedly improved over the years, even if it still isn't perfect.

Potential proper versioning #

This one is still up in the air, but I'd like to move towards proper versioning. This is mostly to pave the way for regular and -bin variants of AUR packages, and to bring a sense of order to the entire project. What's stopping me from going all in on this is feeling like this project is too sporadic and inconsistent with its development to warrant consistent versioning. I'm used to identifying issues and quickly pushing fixes for them, and I would imagine existing users are by now used to these kinds of updates becoming available immediately once they're actually pushed to the repository. In short, my lack of experience with proper versioning and the fact that I don't have consistent free time to work on AeroThemePlasma puts doubts in the attempts I could make. If I were to attempt this, I would likely try my best to follow Plasma's release schedule.

Translation support #

One important missing feature is translation support. In my infinite wisdom, for a long time I decided to completely ignore the use of i18n in most places where translatable strings would be involved, and looking back on it, this was obviously a big mistake. Allowing translation support and making sure to take advantage of already existing translations is going to be a priority moving forward, as part of the process to refactor the codebase to make it easier to work with.

More improvements #

There's a lot to improve, from small things to big things, so here's an incomprehensive list of tasks, in no particular order of priority:

• Minimize animation
• KIO folder preview plugin
• HiDPI support
• QStyle with support for MSSTYLES themes
• SevenTasks improvements (thumbnail animations, better progress bars, multi-row support)
• SevenStart jumplist support
• Refactoring codebases

AeroThemePlasma's unfortunate naming #

AeroThemePlasma was created during Plasma 5's lifespan, and the name chosen was a result of rather uninventive descriptiveness as briefly mentioned before in this post. Back when I started working on (mid-2019) it, it really was just a collection of themes I had found online, that I would slowly tweak to my liking. There was no code involved, besides my select choices of third-party Plasmoids from the Pling store that felt the most fitting at the time, which I didn't dare to modify back then. I had no idea how to work within the KDE ecosystem, and my experience in programming was frankly juvenile, as was I.

Knowing the context and brief history of this project, the name made perfect sense to me back then. But as I started experimenting with more and more code, including both QML and C++ components into the project, this name started to feel less and less accurate in retrospect. I say in retrospect, because there is another reason that resulted in the name staying for as long as it did, that I hardly thought about at the time.

The ill-fated definition of a "Theme"

A lot of people will remember the incident that happened early in the release of KDE Plasma 6, where a Global Theme had mistakenly deleted a large chunk of user-writable files on the filesystem. This briefly raised a lot of alarms and put a lot of doubts on user-generated content that you'd find on Pling. The main question being posed, however, was: How could a Theme do this much damage? Why is there code being executed in a theme?

Prior to this incident (so, the entirety of Plasma 5's lifespan), there was an unspoken assumption that it's normal (or at least, not unusual) for a theme to contain executable code of some kind. With this kind of atmosphere, I didn't think twice about keeping the name "AeroThemePlasma". SDDM themes have QML code, Global Themes have QML and JavaScript code, Plasma applets are all at least QML code, and are regularly recommended with Global Themes. This unconsciously and perhaps incorrectly affirmed my notion that a theme could be more than a set of read-only resources like textures, color schemes and wallpapers.

The introductory blogpost for Plasma Login Manager perceptively points out this detail:

As AeroThemePlasma was adding more and more stuff that was completely replacing core Plasma desktop components, it ended up in this weird state where ATP can't be treated as a simple theme anymore, but it's also not a proper desktop environment either. It was still leeching off of the main Plasma session, directly modifying it instead of attempting to be in its own lane. This gave the project a sort of identity crisis, not having a clear vision of what it is supposed to be anymore. The closest terminology that could have applied to the project was a "modification" or "transformation".

This lack of direction was noticeable in how the project was being managed. The installation method had become ugly, growing in its list of things to configure and install, instead of completely changing the way the project deployed things at its core. Some of these issues still persist today, where we'd ideally want certain configs like the Plasma style and application style to not interfere with the main Plasma session.

Nowadays, it's clear that the name of the project is now a misnomer, but it is kept purely for brand recognition, if there is any to be had in the first place. As for what the project actually is, I suppose that the categorization remains elusive, at least from my perspective.