Bug 434819

Why do we need a text shadow for a standalone folder view applet? The point of the shadow is to ensure text readability against arbitrary wallpapers, but this is not a problem for standalone Folder View applets as they have a background frame. Same with the task manager.

...because the folderview background is not supposed to be opaque enough to allow text ro be read.
As for task manager you've a point, but still i think is a nice effect regardless.

> ...because the folderview background is not supposed to be opaque enough to allow text to be read.
In Breeze it definitely is. Are you using a non-default Plasma theme?  If your theme makes the background so transparent that the text is unreadable, that's really a bug in the theme IMO. Can I see a screenshot of the problem you're seeing?

Nate, i'm not talking about the Breeze theme here, but about the plasmashell plasmoid.
I know Breeze has opaque backgrounds.
In kde4 era the problem has been addressed using text shadows, now it does not anymore.
Is because are we all supposed to use breeze or similar themes but still we are free to choose a wallpaper we like?

It is not a bug in my theme, it is a theme i like because i don't like to have an opaque background under the plasmoids.
I like to have my wallpaper visible *and* i like to read the text over it *and* i like to have icons grouped in the folderview plasmoid.
(And i don't think i've a bugged taste at all).

I made two versions of the theme one more translucent than the other:
7225 downloads: https://store.kde.org/p/998609/
5169 downloads: https://store.kde.org/p/998609/

https://store.kde.org/p/998661/

Can you please share a screenshot that shows the problem you're trying to solve?

Created attachment 136989 [details]
Bright background, low folderview opacity

Sorry, here it is:
Bright background, low folderview opacity

I see from your screenshots how it was better with Oxygen, but the text is still readable with Breeze, even if it's not quite *as* readable.

Making the shadows unconditional is a completely trivial change; remove or comment out "root.isContainment && main.GridView.view.isRootView &&" in line 550 of FolderItemDelegate.qml.

However the result looks terrible with Breeze and I assume any other mostly-opaque theme. So that's not an option.

That leaves a few other options I can think of, in no particular order:
1. Make it a user-facing option (ew)
2. Make it a theme-facing option such that highly transparent themes could toggle it
3. Do some fancy theme introspection to toggle it automatically based on the opacity level of the theme's background
4. Do nothing and say, "sorry this is too niche a use case to care about upstream, and you can patch it out yourself or fork the applet on store.kde.org if you disagree"

I don't feel entirely comfortable making this decision myself so I would like to punt it to Eike. :)

We have four visual elements:

1. The desktop background -> set by user
2. The applet background -> set by theme
3. The text color -> set by theme
4. The shadow -> hard-coded in Folder View applet code

I think the first step would be to make 2-4 consistently set by the theme, as #4 is currently the odd one out that can be disaligned with #2 and #3. This could take the shape of the theme providing a "Text shadows are needed with my applet background" or maybe "Text shadows are needed on the desktop" hint.

This hint should ideally be evaluated by library code, so the implementation of following the hint is applied to all existing applets, instead of just adjusting the FV code (although this solution would satisfy the specific ticket here). So e.g. in PlasmaComponents.Label - the shadow code would move from FV up into the component.

Right now, the Folder View applet code makes the decision to enable/disable shadows based on the piece of information "am I a containment or am I an applet". PlasmaComponent.Label similarly would need form factor/environment information to make the decision. At the moment I'm not sure if we have a pathway to evaluate this sort of information in the Label (e.g. via a pointer to the Applet).

Thanks Eike. So that's basically option 2. Moving to frameworks-plasma since that's where most of the action would take place.

Thanks for looking into this,
I think the folderview should give users the ability to choose:
Text shadows: "obey theme hint,force on,force off".
with obey theme hint defaulting to no shadow if a theme does not provide any.
What do you think?

If we were to add such a set of settings, they would have to affect all Plasma applets, not just Folder View, because logically, you might run into the same problem with any other applet that has a background and labels on it.

My gut feeling is that such a thing might be over-configuration and themes are in the best position to communicate to Plasma whether labels  should have shadows to ensure readability.