On Fri, Dec 13, 2024 at 8:01 AM наб <nabijaczlew...@nabijaczleweli.xyz> wrote: > > Hi! > > We seem to be shipping 3.5 standalone compositors > (maintainers in CC): > 1. xcompmgr ‒ the upstream's effectively finished > (we have 1.1.8, the two releases since changed nothing of > substance) > last maintainer upload 2019-07 > popcon inst=852 vote=171 > 2. compton ‒ fork of fork of xcompmgr, upstream also finished > orphaned since 2024-05 > popcon inst=1121 vote=306 > 3. picom ‒ fork of compton, actually mostly alive? > not in testing > (FTBFS on char=uchar and missing 8-byte atomics, > this is at least partly fixed in 12.4) > clearly missing maintenance resources downstream > (would definitely benefit from being team-maintained) > popcon inst=2221 vote=879 > 3.5. unagi ‒ dead outright (popped up on BOTD) > last updated 2013 > popcon inst=43 vote=7 > > unagi needs to be cut obviously > (preferably with a failover to a modern compositor, > but that's unlikely considering its config is unlike anything else). > > As for the other three... do we need them all? > It's certainly overly confusing. > > xcompmgr users could be mostly-seamlessly upgraded to compton > (AFAICT by comparing the manuals: > xcompmgr has -s/-n (compton is always in -n mode and no flags) > xcompmgr has -a (this is kinda like -s i think?) > and all these do is enable "server-side compositing". > given how the manual describes this, > the usefulness of this seems marginal at first glance, > so the likelihood of anyone using it likewise) > by providing xcompmgr as exec(compton) minus -s, -n, -a; > the interface appears otherwise equivalent. > > The compton -> picom upgrade is harder: compton has > -m, --menu-opacity > -C, --no-dock-shadow > -z, --clear-shadow > -G, --no-dnd-shadow > -S Enable synchronous X operation (for debugging). > --vsync VSYNC_METHOD > --sw-opti > turned into --vsync, --no-vsync > --refresh-rate REFRESH_RATE > (looks replaced with like --no-frame-pacing?) > --alpha-step VALUE > --dbe > --paint-on-overlay > --respect-prop-shadow > --xinerama-shadow-crop > --glx-copy-from-front > --glx-use-copysubbuffermesa > --glx-swap-method undefined/exchange/copy/3/4/5/6/buffer-age > --glx-use-gpushader4 > --xrender-sync > which picom is missing. So, idk. picom'd want to be stabler than it is anyway > (be in testing consistently enough to end up in trixie at least, probably). > > Thoughts? Snark? Have I missed another standalone compositor?
It's worth noting that Lubuntu is currently shipping Picom by default. I don't think you're proposing getting rid of it, but if that ends up being considered, I'd prefer if it could be kept around or if the Lubuntu team could adopt maintainership of it. As for the others, is there any reason they can't just use the existing systems to decide if they're removed or not? i.e., if there are maintainers paying attention to them, let them stay. If they develop release-critical bugs, they can go.
