Bug 505936 - Customize color and transparency of background for Quicklaunch widget
Summary: Customize color and transparency of background for Quicklaunch widget
Status: CLOSED INTENTIONAL
Alias: None
Product: plasmashell
Classification: Plasma
Component: Quicklaunch widget (other bugs)
Version First Reported In: 6.3.5
Platform: Other Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-21 20:22 UTC by Nikoichu
Modified: 2025-06-26 15:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikoichu 2025-06-21 20:22:15 UTC
It would be nice if the background color and transparency was customizable via a RGBA color picker. Also a checkbox that causes it to blur the wallpaper behind it would be a nice addition also.
Comment 1 Nate Graham 2025-06-24 16:42:20 UTC
The wallpaper already gets blurred in Plasma 6.4. A customizable background color is isn't something I think we'll be implementing, sorry. There would be too many opportunities for people to set a color that made icons or text unreadable, and then they would do it anyway and submit bug reports about it. :)
Comment 2 Nikoichu 2025-06-24 17:08:44 UTC
(In reply to Nate Graham from comment #1)
> The wallpaper already gets blurred in Plasma 6.4. A customizable background
> color is isn't something I think we'll be implementing, sorry. There would
> be too many opportunities for people to set a color that made icons or text
> unreadable, and then they would do it anyway and submit bug reports about
> it. :)

I see. The reason I asked for this feature is because I want to make the background (almost) fully transparent, so they look like regular desktop icons, since I got tired of my desktop icons rearranging themselves.

People can already mess up their UI visually if they really want to, so I don't think anyone will be opening bug reports about a color they chose themselves. Implementing custom BG colors will allow users to make different "groups" of app launchers and organize them by color, which could be useful to some users.

Either way, if not full color customization, at least consider a transparency slider, please. :)
Comment 3 Nate Graham 2025-06-25 19:52:05 UTC
We should just fix the bug with the desktop icons re-arranging themselves! Features designed to let people work around bugs rarely work out well in the long term.

> so I don't think anyone will be opening bug reports about a color they chose themselves

Oh my goodness, how I wish that would be true! Alas.
Comment 4 Nikoichu 2025-06-26 05:55:11 UTC
(In reply to Nate Graham from comment #3)
> We should just fix the bug with the desktop icons re-arranging themselves!
> Features designed to let people work around bugs rarely work out well in the
> long term.

While I agree that bug should be fixed, since switching over to the quicklaunch widget instead, I have come to prefer it over traditional desktop icons, since it has several benefits over them, including not cluttering your desktop folder with shortcuts, having even spacing and unlimited size, more control over placement and size independently from icon grid, etc. It's a really great widget! So this is no longer a "workaround" for me.
I've gotten used to the dark background on these widgets, but I'd still prefer if I could customize it to my liking by increasing its transparency if possible, since they do obscure my gorgeous wallpaper :D

Another solution for the custom color thing to consider could be a selection of pre-defined colors that are guaranteed not to make text/icons unreadable, instead of a full-on color selector. Something similar to the file label colors.

Either way, the transparency slider is more important to me than this custom color shinanegans :)
Comment 5 Nate Graham 2025-06-26 15:50:06 UTC
No, sorry. This widget is low priority, and, again, implementing features to work around bugs — even if they can be re-construed as useful on their own were the bug to be fixed — isn't generally something we do.

If someone submits a patch to implement this feature that seems reliable and won't increase maintenance burden, we can consider it, but until then, I don't think there's much sense in keeping the ticket open.