Focus focus color is replaced by font hover color

[rafaelcastrocouto]

Godot version

v4.0.stable.official [92bee43]

System information

Windows 10

Issue description

Focus color (and styles) should always override hover colors (and styles)
I was expecting 4.0 to fix this since the 'Theme overrides' panel has been updated but the hover color still will replace the focus color. This creates confusion when changing focus and is definitely an accessibility issue.

Steps to reproduce

1. create a button
2. add a custom focus color
3. add a custom hover color
4. run and check the behavior

Minimal reproduction project

https://github.com/rafaelcastrocouto/RichTextLabel

zip file: RichTextLabel-main.zip

[rafaelcastrocouto]

Seems like the problem lies on the button.cpp file, I'll try my best to make a PR to fix this.
https://github.com/godotengine/godot/blob/master/scene/gui/button.cpp#L130

[YuriSizov]

Please make a proposal if you think the current rendering logic of control nodes need to be updated, explaining your use case.

I am also not sure what the theme overrides section has to do with anything.

[rafaelcastrocouto]

The case is the same that lead to the addition of new states in 4.0 (like hover_pressed). There are cases where focused + hovered need their own styles (specially when the button has no background).

The theme override panel is the fatest way to check this behavior without getting into 'theme territory'.

If you don't understand you could just ask, or wait in silence and check a possible future PR, but u went straight to closing it, really? That's beyond rude, I mean, not even waiting for some feedback or an attempt of a solution.

I have no idea why you would go on with this behavior but that sure is way too far from the open source mentality.

If the issue had a negative feedback your attitude would make sense but this .. OMFG.

[YuriSizov]

I asked you to open a proposal because this is not something that fits a bug report.

The part I didn't understand is not relevant to the proposed change. You can do the same in Godot 3 and theme overrides there. Nothing changed about it, so I was confused why you thought there were any changes.

[rafaelcastrocouto]

This does fit a bug report because removing the focus style leads to a failure in accessibility tests

[YuriSizov]

I'm sure you can "win" this verbal argument, but I'm still asking you to follow the procedures of this project. Opening a proposal does not in any way diminish the issue at hand, but it allows you to explain in a more formal way why this matters and what steps are needed to improve the situation. And you can still make a PR if you so desire.

Following instructions of open source maintainers helps us keep workflows of the project organized and keep tasks at hand actionable. Listening to feedback from maintainers helps you make successful contributions. My request was simple, but requests made during the review process can be much more complex, so I would urge you to find it in yourself to cooperate with us instead of creating a pointless conflict. Thank you for your understanding.

[rafaelcastrocouto]

1. This is not about making a PR, anyone can do it at any time and that is common knowledge;
2. This is not about following the procedures of this project since this is not a feature proposal and the guidelines are pretty clear about it;
3. This is not about creating a proposal, I would do it happily as I've done before (although it would make little sense to create a proposal asking if we should follow basic accessibility standards);
4. This is not about organizing the "workflow" of the project since making a proposal issue would result in exactly the same environment for discussions.
5. This is not about winning an argument, imho we all lost here when a single person decides to take action without understanding the context and harshly pushes away new contributors.

This is about empathy, about treating others with respect, about not being rude and about not taking decisions without the minimal community participation. You might close a bunch of issues every day but some of us spend a couple of hours making sure we are not making a mistake ourselves, and creating clear projects to assure it's an issue and going through the code to try to spot where it can be fixed.

I'm not claiming that I'm "right" and this issue should be fixed, I'm claiming that u handled this the worse way I can expect from an open source project member.

I'm unsubscribing from this issue so there's no reason to waste your time with a response, instead go back through your own thoughts and try to be mindful not only about your tone, but also about your attitudes.

[akien-mga]

Edited after further discussion with the production team. I wanted to put an end to the escalating issue yesterday but also chose my words somewhat poorly.

We agree that the issue being reported is a problem that would be worth solving. It is currently the expected behavior of this API, and as such we are asking to open a proposal for changing it in https://github.com/godotengine/godot-proposals/issues, which has a more in-depth template and focus on discussing what the intended behavior should be, how to handle the compatibility with the existing behavior, what the API should be like to be user-friendly, etc.

In our workflow, this is not a simple bug with a simple fix, it's something that requires a holistic approach and that's what the proposals workflow is for.

We acknowledge that the issue was closed a bit abruptly, and that the justification I gave above needed to be better communicated. I can assure that there was no ill intent, and that we didn't mean to be dismissive of the issue at hand.

Regarding your last comment after the issue got heated, I would ask that you refrain from using contributors' past writings on their personal blog to make arguments against them, as this is against our Code of Conduct.