Should add Usability and design experts to reviewers.
As far as I am concern, I don't see much use of adding an option (and the code complexity that goes along), in order to disable a rather core (and very usefull, usability wise, in my humble oppinion) feature ...
I'd rather have the patch kept downstream, (and rebased when necessary) rather than having to maintain it myself (since I don't see the added value of this patch, for "general" users.
Sorry.

Hugo

(for me at least, hover effect is something very useful to identify that an item is clickable. Admittedly, this is not very necessary for buttons, but for things like expander and scrollbar arrows, which otherwise appear just like text, it certainly helps).

The added value for users is getting regular bugfixes from upstream Breeze. After extensive experience with Oxygen and Breeze forks by distros over five years, they basically always got outdated. I'd much rather maintain this option upstream (which I can offer to do for you) than look after a fork zoo.

BTW I'll add this is a very common predicament in FOSS and it's the reason why kernel.org has a "code should be upstream" and "if real systems ship it, we should merge it" policy. History/experience has shown again and again that downstream deltas end up being a problem - bugfixes don't get distributed, downstreams do work redundantly, etc.

Regarding the general topic of "to hover effect or not to hover effect", I personally see the utility of hover effects and am fine with them being on by default. However, it's also true that other systems seem to do fine without them and I can see how some might prefer a calmer, more stoic UI. I think it's a decent area for downstream differentiation/flavoring by differing defaults.

I'm not so much talking about the value of having the code upstream (of course everybody wants their code upstream, to get relieved from the maintenance burden), but on the feature itself, which in my opinion is too little to be upstreamed.
as for the offer for maintaining the change, thanks for the offer but that is not how it works. Either you would step in as an official breeze maintainer, or I would have to dispatch bugs to relevant people who orriginally did the commit. Which is an extra burden for me. (I know: this already happens for the wayland stuff, of which I know nothing). Beside, for every change I would have to make in the future, I should also be responsible for breaking this extra feature which in itself I don't find usefull.

Again. Some insight from VDG and UX folks would help.

I don't see VDG/UX input helping on this issue. We know there are working systems that behave in this way and are usability-tested. The VDG could only give an opinion on what it wants to see in Plasma by default, and this patch doesn't aim to change a default. It's an opt-in preference.

And "or I would have to dispatch bugs to relevant people who orriginally did the commit" is exactly how it works in KDE.org, cf. "Common ownership" on manifesto.kde.org or any multi-developer project (such as Plasma itself) where different parts of the whole have different default assignees. Basically what I'm saying is that if I contribute this option to Breeze, I'm fine with being responsible for testing it in the future and checking that it keeps working correctly. I don't think "$codebase can only have code added that $maintainer needs/wants" scales well, and tenets like common ownership are designed to address the need to scale.

... VDG also gives oppinions about what should be an option and what should not

Aye. I've pinged Jens, Ken and Thomas with the link.

If it's most likely to be decided only on the distribution level, we don't necessarily need a GUI for switching it, do we? We could also just have it as an unexposed parameter in the config file.

I think Breeze (like Oxygen) already has too many user-visible config options. That said, it's also difficult to argue why all the ones that re already there are more likely to be switched by users than this one.

In the end, however, I'd say that having mouse-over effects was a design decision in Breeze just like other aspect of it, so I don't see why users should revert that decision.
So, would having it in the config file but not in the UI be a viable path?

If it's most likely to be decided only on the distribution level, we don't necessarily need a GUI for switching it, do we? We could also just have it as an unexposed parameter in the config file.

Yes, although options being hidden tends to excercabate maintenance issues.

In the end, however, I'd say that having mouse-over effects was a design decision in Breeze just like other aspect of it, so I don't see why users should revert that decision.

Well, Breeze also made design decisions to offer various other options.

The reason to have options in a style engine vs. having another style engine with a different set of design decisions usually comes down to the fact that a style engine is a huge C++ codebase that's a lot of effort to create, and while the style engine system does support inheritance to some degree, the support for inheritance doesn't easily extend to overridding behaviors such as this. That's why the realistic options are an option in Breeze or a fork that's likely to get outdated.

This is also why there's engines like the highly configurable QtCurve (and a big aftermarket of 500+ QtCurve themes/config on the KDE Store), instead of 500 different style engines.

"This is also why there's engines like the highly configurable QtCurve (and a big aftermarket of 500+ QtCurve themes/config on the KDE Store), instead of 500 different style engines."
That is out of topic
Breeze is not QtCurve, and possibly, it is because QtCurve has a zillion design options that it is not kde default theme. (in fact: why not add this option to QtCurve and make the distro you use use this as a theme instead of breeze ?)

To summarize:

• Colomar thinks that mouse hover is a design feature for which there should not be a visible option
• I think it is a usability feature that should not be disabled (hidden option or not)
• I am not convinced by your arguments as to why this change is needed, (as much as you are not convinced by mine as to why I don't want to accept this patch),

Concerning the remark ""I don't think "$codebase can only have code added that $maintainer needs/wants"
(which is out of topic and not very pleasant):
Needs: I agree 100%
Wants: maybe not, but "accepts" certainly yes, since I later engage my responsibility to users for maintaining this added feature.

I don't accept this change (though I do not know how to do that in Differencial).

Sorry. This will have to be kept downstream.

I think it's regrettable that the current Plasma default theme isn't interested in satisfying the needs of our downstreams and do wonder if that situation will have to be addressed somehow, but thanks for your input.

"I think it's regrettable that the current Plasma default theme isn't interested in satisfying the needs of our downstreams and do wonder if that situation will have to be addressed somehow,"
I think this is a completely overstated and innapropriate statement Heike.
please refrain, disregarding the frustration you feel

ps: is there a bug (= wish) report somewhere about this so importantly needed feature ?

At least we could explain there to our user why we would prefer not to implement the said feature
(as I have done politely multiple times already, without ending up being accused of not trying to satisfy the needs for our dowstreams)

Colomar: could you also comment on "https://phabricator.kde.org/D5429" ?

No, inappropriate is stuff like "which is out of topic and not very pleasant" in a rational discussion over contribution and maintance workflows in the KDE community (which you started). It's even more inappropriate to resort to ad hominems suggesting I act out of frustration.

ps: is there a bug (= wish) report somewhere about this so importantly needed feature ?

No, I'm not aware of a ticket, sorry.

I'd prefer postponing this until we can use QStyleHints useHoverEffects at which point we can make it global for Plasma and all other places.

Can you tell us more about QStyleHints useHoverEffects? Is this a real thing that's coming, or a proposal?

http://doc.qt.io/qt-5/qstylehints.html#useHoverEffects-prop

I think that's exactly what we want (added in Qt 5.8)

I think QtQuick Controls 2 already use it for whether they accept hover events by default.

Then we'd need to adapt Breeze to follow the style hint, and put a global option into the Style KCM to set through the QPA?

In the Plasma QPT, yes, we already have something similar for whether to use animations iirc in widget style advanced settings

To go one further, we could add a mechanism to allow downstreams to set the style hint via the LnF package, then we (maybe) don't even need the checkbox.

In D5428#101932, @hein wrote:

To go one further, we could add a mechanism to allow downstreams to set the style hint via the LnF package, then we (maybe) don't even need the checkbox.

+1
breeze should follow the hint then

You cannot repurpose useHoverEffects.

The documentation says that is for disabling hoverEnabled on a bunch of items - so they don't even get hover events.
(albeit only in QtQuickControls2 ...for now) because it has a high performance cost.

Despite it's name it is not for "style", use would surely break a lot of things.