Most dependency injection frameworks support initializing the components being injected with various parameters, typically read from an XML configuration file.
This seems like a very convenient place to store settings (like a server name, or a file path that the component will need). But is that the right way to go, or would it make more sense to have a seperate configuration file for settings ? And does it matter, in your opinion, whether the user should be able to change the settings via UI ?
I would probably store the settings in a separate file, to make it more clear what settings might need modification in different environments. This also makes it easier for people not familiar with your dependency injection framework (e.g., system administrators, end users) to modify the settings.
If this is a very small application, and the settings will only be changed by developers, I might keep the settings in the DI configuration.
IMHO, it's a matter of common sense. Usually, I keep everything in the same config file, but in different sections. If you use too many config files, it will be harder for someone new in the team to understand your code, for example. But if the file is getting too big, I think it's ok separating them.
About the UI settings, I think developers should make most of the choices, but open some space for configuration. I don't have the link right now, but there's an interesting story of a store which used to sell jam. They would let the customers taste the jams with toast, which highly increased sales (for customers would know the quality of what they were buying). In the beggining, they didn't have many jam options (just 3), and it was a success. When there were too many options (like 20), they noticed customers got a little confused with so many options.
Another reason for reducing configurability is to reduce development time. If you read the book Getting real (I recommend this one), they say a lot of time to build less. In chapter 10, they say:
* Less software is easier to manage.
* Less software reduces your codebase and that means
* Less maintenance busywork (and a happier staff).
* Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code. Less software results in fewer bugs.
* Less software means less support.
So, IMHO try to find out which settings users would like to change most, and make these configurable. Also, if your system is already at production, and keeps growing slowly, I think you could open more space for configuration as time goes by. Gmail, for example, didn't have many configuration options, but as users got used to the tool, they started creating options for the users, like changing themes and other features of google labs. This way, the learning curve "doesn't hurt" users :).
Hope I helped.