Consider creating a teracom repo/project

[MitchMG2]

The compton rename to picom was selected out of being the combination of the words pico and compositor, aka "tiny compositor" in the spirit of it being lightweight. "Pico" is 10^-12 in the metric scale , the opposite of that is 10^12. This produces the prefix "Tera".

There have been numerous forks of picom popping up with more and more eye candy. The dual kawase blur feature was implemented thanks to the large involvement of it's author tryone144, and right now there is an attempt to implement the sdhand/ibhagwan rounded corners feature, which seems to require a large rewrite of the core compositing code.

Im already seeing another fork with window animations pop up and am beginning to wonder if as more an more visual featureforks show up, if they detract too much from the main core compositor development. Im looking at the projects page, and the biggest priority seems to be getting the new experimental backends to be less buggy, looking into EGL and Vulkan, deprecating the legacy backends, working nicely with xorg, not to mention the entire mess with nvidia drivers being a pain to work around.

Im calling it now, there will eventually be a pull request for the return of the 3D desktop cube of days old, thus putting this in compiz terrirory. This slippery slope has me wondering if a separate "teracom" project should be created with more focus on the eye candy stuff, leaving picom to be the "lightweight compositor" it was meant to be.

[Mark42XLII]

Honestly, with stuff like #217, I'm afraid of that as well. It's not like I'm against those features (although I wouldn't use them myself), but I think stuff like that should be kept as a separate project, certainly not in picom. Maybe turn it into a series of patches that get applied to picom and then built as its own separate thing. I think once a feature needs more core rewrites and hacks to be implemented than benefits it can bring, that's where the line should be drawn: it's very likely it will break working features and diminish hardware and software support even further.

[yshui]

Maybe turn it into a series of patches that get applied to picom and then built as its own separate thing.

That's not going to be a sustainable development model.

It is difficult to balance the complexity of the codebase vs. the features users want. I will be trying my best to make the right call, but also I am aware I won't be able to please everyone all the time.

[tryone144]

Just for reference, there is a feature request to modularize the codebase: #312
How doable this is for different rendering-effects is a whole different story…

[yshui]

@tryone144 being fully modular really opens doors for us to become compiz (which is still alive, btw). I don't know if that's what picom should be.