I'm doubtful this will get implemented unless someone (maybe you? :) ) submits a patch. Or more likely, a serves of patches, since we'll need to expose the config UI for it.

I am not a developer.

One property setting change in two locations and an additional UI checkbox is too much?

Well, everything is always harder than it seems. :) 

Regardless, you may not think of yourself as a developer, but you can clearly think logically and read and interpret source code. That's 90% of the way there! It's no less that where I started from when I began to submit small patches here and there. Give it a try. :)

Happy to test for FOSS projects, report issues, follow up afterwards.

As I said, I don't develop. By choice.  I hate coding.  Tried it.  Detest it.  Life is too short to do stuff you hate.  Not happening.  Ever.

Trawling through the breeze code to find a solution to this felt like Andy Dufresne's 500 yard crawl through raw effluent in Shawshank.  Unpleasant.

But I found a solution anyway.  A very simple solution.  Trivial actually.

WallpaperFader.visible = false

In two places.  That is all.  Been using it since 5.24.3 and works.  Perfectly.

Even that is not enough.  Write the code yourself.

Your irrational inflexibility to implement this simple disable mechanism for a UI element that is invasive, ugly and ultimately pointless is very weird.  

My system works fine now, be nice if others had the same option.

Guess not though.

This discussion makes me sad.

Nate has not rejected your idea, he is just telling you that this can be only implemented if someone is actually interested to do it *and* is not busy working on something else. He is kindly inviting / encouraging you to contribute some code. This kind of invitation may help getting people a bit shy to overcome their timidity and contribute. You seemed to know your way, that's why he did that. He could not have guessed you actually hated programming and this should not be taken as "then do it yourself, duh!". Of course nobody forces you to do it and if you don't like programming, that's fine!

But it means you'll have to wait that somebody takes your idea and implement it. If you want to see this happen, you need to make people want to implement it. For this, you need to be nice to them and humble.

It may be simple to implement but someone still needs to spend some time to do it, most likely in their spare time. There's no "irrational inflexibility" in not spending this time. Like you say, rational people may want to spend leisure time in something they like to do. It's not that they are actively against doing it, it's just that the incentives are not high so it'll not get done, through inaction. There are ways to increase the incentives, like offering a bounty for instance.

Nate was nice to give you an answer and has done the best he could to hint at a likely outcome to your idea without rejecting it. You now have all the cards in your hand. He actually hinted at "yes, we might accept a patch that implements it", which is almost the best outcome for an idea (the best one being "I want to implement this", assuming the idea has been accepted).

Everyone is well-intentioned, let's take a moment to take a step back. Everything is fine.

I would like to better control this blur effect, form 100 to 0 (i.e. disabled). I have done the same thing, disabled the fader as described here, as my Invent account was disabled/removed and could never recover it again, so I feel truly discouraged to investigate the technical aspects on how to implement a configuration and provide some patch for it.
It may be a matter of taste, but really, I could not find an image to look good with this effect so far.

Hi, what would be the accepted solution from the UI methodology point of view? I mean, adding a setting is easy, but how should this be handled by the user? This blur effect may not a standard part of any SDDM theme, so it looks like a dynamic approach is needed, like a setup button on the theme item in the settings add-on that would parse supported theme parameters definition and provide a UI to edit them. This sounds good, but not simple to implement. Would this be too much for maintainability or user perspective?

Since the feature to be made optional is specific to just the Breeze themes, it would ideally be shown in a location that makes it clear that it applies only when using that theme. The Lock and Login screen KCMs would need to be adjusted to learn how to read and display UI elements for such settings.

Thinking of it, the most natural way would be to add an icon (action icon) along with the others for details and background, visible when custom settings are present, to access a setup control specific to the theme. The responsibility for the implementation would fall on the theme code. That's because I am not sure how generic solution could be implemented to parse custom settings and make them editable by controls for any case. Maybe some generic approach for specific cases and add a way to use custom implementations too. Not so simple  either. What would be acceptable, ideally?

I think your idea makes sense. It's what we do for Application Styles and Window Decorations.

Application Styles and Window Decorations are two different implementations. I see Window Decorations uses DecorationBridge where:

//
//  W A R N I N G
//  -------------
//
// This file is not part of the KDecoration2 API.  It exists purely as an
// implementation detail.  This header file may change from version to
// version without notice, or even be removed.
//
// We mean it.
//

Application Styles is much simpler and seems to suit the need of this bug.
Am I right?

Pursuing Application Styles, there is a suitable StyleConfigDialog that worth reusing for this, as placeholder for the actual config dialog. If so, where would this be placed as a common component?

Also Window Decorations seems suitable, with regards to loading of a config dialog directly on the KCM page, in order to blend the  already implemented pages of the SDDM themes settings.

Back to the issue, reading and learning to be able to solve it, while waiting to move to 6.

What would be the best solution out of the following:
1. Enable/disable WallpaperFader component completely
2. Set the opacity on the WallpaperFader component from 0.0 to 1.0?
3. Refine the blur effect?

1 or 2 are simple to implement.

For 3., I have no idea how. I've tried to change it live in the QML file, which is WallpaperFader.qml in the system files, while running Plasma, but it does not seem to have any effect even though I've restarted the system entirely.
Would be nice to be able to vary the blur effect by a slider.
Any hints?

What would there be an acceptable solution from the main Plasma team perspective?

As a side comment, I'd like to have the same image in the SDDM and the splash sequence, meaning be able to add/use the same image to the splash screen as from the SDDM, maybe lock screen too.

If we move ahead with this, 1 and 2 are fine. 1 is more technically correct, but probably a bit trickier to implement properly. Personally I'm fine with adding an option for it.