slower/less sensitive for a sliding bar in a specific gui menu
I’ve never heard of such a requirement for any reason, and I’ve been around for a while and tend to read more than a little. As I wrote in another comment, I’ve only heard of the originally mentioned scrolling speed being a nuisance when the app doesn’t follow the system-wide settings. So the tradeoff of the demand to cost of implementation and support isn’t in your favor.
Configuring this would be quite cumbersome — the user would need to specify the whole hierarchy of UI elements for the specific window, including intermediate invisible elements. Whereupon the app would just offload that to the GUI framework, which presumably would handle the functionality and add that to the myriad of aspects that it must handle already.
However, this is probably already possible to implement in MacOS without any need for ridiculous configs on the part of the app: via a separate app using accessibility APIs. Iirc those APIs can report the UI elements that the user is engaged with — and if it reports the cursor hovering too, then the app could change the cursor speed dynamically. It’s possible even that Hammerspoon, programmable in Lua, can do something like that. Of course, apps not made with the native Cocoa framework break this and other accessibility functionality.
As for the colors of the windows, there comes a time in the life of a man when they realize they’d like to get shit done instead of fiddling with customization, and for the UI to fade away and do its thing quietly. I’ve seen it happen.
I’ve never heard of such a requirement for any reason, and I’ve been around for a while and tend to read more than a little. As I wrote in another comment, I’ve only heard of the originally mentioned scrolling speed being a nuisance when the app doesn’t follow the system-wide settings. So the tradeoff of the demand to cost of implementation and support isn’t in your favor.
Configuring this would be quite cumbersome — the user would need to specify the whole hierarchy of UI elements for the specific window, including intermediate invisible elements. Whereupon the app would just offload that to the GUI framework, which presumably would handle the functionality and add that to the myriad of aspects that it must handle already.
However, this is probably already possible to implement in MacOS without any need for ridiculous configs on the part of the app: via a separate app using accessibility APIs. Iirc those APIs can report the UI elements that the user is engaged with — and if it reports the cursor hovering too, then the app could change the cursor speed dynamically. It’s possible even that Hammerspoon, programmable in Lua, can do something like that. Of course, apps not made with the native Cocoa framework break this and other accessibility functionality.
As for the colors of the windows, there comes a time in the life of a man when they realize they’d like to get shit done instead of fiddling with customization, and for the UI to fade away and do its thing quietly. I’ve seen it happen.