But if this is in a config file for an individual app or piece of software, I’d assume it would be importing the default, system-wide settings in some capacity. Even if it wasn’t a default setting in the config, being able to add modifiers to otherwise default settings isn’t the same thing as burying a setting under several layers of menus.
It can be shipped with a default mode of “this is how we intend this software to be set up and used”, and then the 500 page manual for “customize at your own risk”.
It just seems like there are several steps between “all the options” and “no options”. And changing cursor speed, for example, could be an accessibility thing. Needing to be slower/less sensitive for a sliding bar in a specific gui menu, but can be normal speed for the rest of the system.
Or if I want to change the colors of different windows. Whether for organization purposes, or to fit a theme, or whatever. I just thing getting to play around with and customize some of that stuff is neat, so it’s nice to hear the other side of why that customization wouldnt be allowed, even if I’m still unconvinced in this instance.
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.
But if this is in a config file for an individual app or piece of software, I’d assume it would be importing the default, system-wide settings in some capacity. Even if it wasn’t a default setting in the config, being able to add modifiers to otherwise default settings isn’t the same thing as burying a setting under several layers of menus.
It can be shipped with a default mode of “this is how we intend this software to be set up and used”, and then the 500 page manual for “customize at your own risk”.
It just seems like there are several steps between “all the options” and “no options”. And changing cursor speed, for example, could be an accessibility thing. Needing to be slower/less sensitive for a sliding bar in a specific gui menu, but can be normal speed for the rest of the system.
Or if I want to change the colors of different windows. Whether for organization purposes, or to fit a theme, or whatever. I just thing getting to play around with and customize some of that stuff is neat, so it’s nice to hear the other side of why that customization wouldnt be allowed, even if I’m still unconvinced in this instance.
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.