I'm more than happy to discuss stuff that's actually likely to produce useful information, and it's relevant to using DOpus.
(See here for example: [Is DOpus right for me?:: history of last N raw commands)).
Notice how no one interrogated anyone else for complete and thorough justification on "why" they would want such a feature in the first place.
It doesn't have to be purely "yes/no" ... just try to stay on topic, that's all I'm asking.
We have a number of admins here who are more than capable of determining what is and isn't 'on-topic' thanks.
You're welcome. I'm also happy to let people ask me personal questions about why I do or do not like this or that hypothetical yet-to-be-implemented-feature that no one seems to want or even have a clue about in the first place besides me.
Just don't be surprised if I consider such questions off topic, and I don't ask a capable admin for permission not to explain.
Sorry, I said I would ignore this thread but I can't resist following up:
[quote="dreftymac"](See here for example: [Is DOpus right for me?:: history of last N raw commands)).
Notice how no one interrogated anyone else for complete and thorough justification on "why" they would want such a feature in the first place.
It doesn't have to be purely "yes/no" ... just try to stay on topic, that's all I'm asking.[/quote]
Nobody asked you why you wanted the CLI/history thing because:
[ol][li]We understood why it was useful without the need for further explanation. That happens sometimes! Other times we don't understand at first and ask for more information so that we can get a clearer picture. We're not mind readers but, equally, we don't ask people questions that we already know the answers to just for the sake of it.
[/li]
[li]The thing you asked for in the other thread is not already possible, unlike the subject of this discussion where, as far as you have allowed us to understand the issue, you can already solve the problem in the ways that have been put forward.[/li][/ol]
If you had properly explained why you wanted to move and/or backup your configuration in a way that isn't already possible, and entertained discussion on the details of how it should work, then I suspect the feature would have been implemented by now. It is probably a trivial change to make, but: (a) It can't be made until the requirements are properly understood; (b) No code change should be made unless there is a good reason for it as every change can introduce new bugs. As noone but yourself understands the requirements or the benefit of the change, the change will not be made (unless someone else comes along and puts forward the case).
Clearly you think the feature is useful and relevant, else you would not have mentioned it or called the lack of it a major deficiency (or whatever the phrase was), so I don't see how a discussion which would've resulted in that feature being added to Opus (assuming your reasons for needing it weren't crazy, obviously) could possibly be seen as irrelevant or unuseful.
[quote="dreftymac"]Just don't be surprised if I consider such questions off topic, and I don't ask a capable admin for permission not to explain.
[/quote]
Equally, if you start a thread asking for a feature which you say is a big deal, don't be surprised yourself when other people are surprised that you refuse to support what you put forward with even the smallest of details.
Boaahhh, nice thread. Now its my turn 
I can provide at least one reason for having the configs of programs in one location. It will reduce the backup script from (Pseudo-Code)
copy a_config to backup\a_setting
copy b_config to backup\b_setting
copy c_config to backup\c_setting
copy d_config to backup\d_setting
to
copy config to backup\setting
As you may see the latter is easy, clean and maintainable. Not like the first one.
For the programs this would mean that they indeed have a pointer to the configs, but this pointer is not worth to backup because it can be restored at install, like some of guys here have said
That is may point of view.
Remark:
I have read through this thread twice!!! And indeed the issue was not that someone is unwilling to understand but the lack of reasons. If someone has tons of reasons and examples she/he shall post it here and everyone interested will look at them and maybe they are convinced. That is what this forum is for.
Additionally, the sandwich shop is exactly an example for explaining the reasons of a request. In every restaurant or similar I know you are welcome to tell your opinion, make change proposals, etc., they even have special forms for that. BUT you always have to explain WHY if you REALLY want to have changed it. Otherwise the owner will dismiss it, because she/he may see no benefit. Why and how do companies make surveys? Because they want to know WHAT and WHY things have to be changed.
Hopefully this reply is deemed useful for EVERYONE 
Thanks! 
[quote]It will reduce the backup script from (Pseudo-Code)
copy a_config to backup\a_setting
copy b_config to backup\b_setting
copy c_config to backup\c_setting
copy d_config to backup\d_setting
to
copy config to backup\setting[/quote]
IMO, the top script is more lines but is very similar, or maybe even less, effort.
If you reinstall a program or move to a new computer and reinstall everything, you don't have to edit the top script, provided it's well written (i.e. works relative to %APPDATA% or a similar path).
With the bottom script, if you reinstall a program or a computer you have to tell each installer where you want each program's config to be kept again. (Of course, an update install won't require that as the installer can look up the existing settings dir, but the top script is still no more effort in that case.)
You only have to edit the top script if you start or stop using an application completely. When you do edit it you provide the same amount of information as you would if an installer asked where you'd like the settings to be. (Though I admit it can take time to track down where a program stores its settings. So asking in the installer does add 'discoverability' which is definitely good. The installer could just say "this is where your settings are", though.)
It also stops people who don't know any better moving their settings to silly locations, like Program Files, and means fewer questions are asked during the install, both of which are minor pluses, but pluses all the same.
Just my personal take on it, though. I'm not the gatekeeper who decides whether this gets implemented or not.
... so in other words, the person gave what was (in his or her opinion) a legitimate rationale, and you say why you disagree, gee! I didn't see that coming! ...
... so in other words, inexperienced people are protected from themselves, and people who do know exactly what they are doing are also protected from themselves. Perhaps we can just outlaw trial-and-error mistakes and independent thought entirely?
Yes, exactly, it's your personal opinion. I think your opinions are 100% flawless ... for you.
... and they wondered why I didn't want to elaborate ... 
@xbprm: Good post, it is useful and I agree with you.
Just to be clear, I do not mind sharing ideas and even taking a survey or even having people explain why my idea(s) may not be so good (especially if they offer alternatives or explanations to help me learn something I may not have realized before).
I would never, however, expect to take a company survey where (at the end of the survey) the company (or enthusiasts of the company) persistently nag me to "justify" why I answered the way I did or berate me for not engaging in a game of en.wikipedia.org/wiki/Regress_argument.
If someone hears your counter-explanation, and they still don't change their mind, and they say they don't feel like discussing it anymore, at some point you have to just respectfully agree to disagree.
[quote="nudel"]
If you reinstall a program or move to a new computer and reinstall everything, you don't have to edit the top script, provided it's well written (i.e. works relative to %APPDATA% or a similar path).[/quote]
And what to do if the program doesn't provide such environment variable? Dig into the registry? I could do that but I think 90% of all users don't!
[quote="nudel"]
With the bottom script, if you reinstall a program or a computer you have to tell each installer where you want each program's config to be kept again.[/quote]
Yes, but how often do you reinstall windows from scratch? If you don't do it every day I think its worth it.
[quote="nudel"]
You only have to edit the top script if you start or stop using an application completely.[/quote]
Second script I do not have to change at all 
[quote="nudel"]
When you do edit it you provide the same amount of information as you would if an installer asked where you'd like the settings to be. (Though I admit it can take time to track down where a program stores its settings. So asking in the installer does add 'discoverability' which is definitely good. The installer could just say "this is where your settings are", though.).[/quote]
Not every program stores its settings in xml like DOpus does (Great feature for someone who likes to dig into settings like me)
For normal users you have the normal install and for people like me or dreftymac you have the custom install, where you can make your make very own settings/wishes.
One more reason I have which someone I think has already mentioned. I am very keen on experimenting with programs. Push them to the limit etc. So if I do change settings I would like to find them easily every time I search for them. If they are distributed all over my various hard disk, ini-files, registry settings I always have to search (Lotus Notes is very bad example BTW). If I would know that they are at a certain location it would make comparisons of changes much more comfortable.
[quote="nudel"]
Just my personal take on it, though. I'm not the gatekeeper who decides whether this gets implemented or not.[/quote]
I think we have said enough. If someone would provide more reasons we can make a submission to GPSoft and hope for the best.
Someone gave their rationale and I replied saying, "but have you considered this?" What is wrong with that? If an idea is put forward but there might be a better way to it, for reasons that hadn't been considered yet, should we all ignore that and still stick to the original plan? If their way actually is better, for reasons I haven't considered, then they can explain that.
People who know exactly what they are doing can still do what they want via the methods I've described, which seem to have advantages to them as well.
I've backed up my reasoning with logical arguments.
Your opinions may be flawless to you as well, but you are not the only Opus user in the world. If a change is going to be added I believe it should be looked at critically and alternatives explored. You seemed to be set on things working in a certain way without thinking of the alternatives, which I don't think is a good way to design features, so I challenged that by asking some questions. Is that so wrong??
I had assumed, since you rejected the alternatives and seemed to feel very strongly about it, that you had good, logical reasons for wanting things to work differently. Perhaps I was wrong. I wanted to understand those reasons. If they made sense to me I'd change my mind.
If you had nothing to add to the discussion then you could've just said so, instead of pretending that there was a variety of reasons behind your thinking which you just couldn't tell anyone.
[quote="xbprm"][quote="nudel"]
If you reinstall a program or move to a new computer and reinstall everything, you don't have to edit the top script, provided it's well written (i.e. works relative to %APPDATA% or a similar path).[/quote]
And what to do if the program doesn't provide such environment variable? Dig into the registry? I could do that but I think 90% of all users don't![/quote]
%APPDATA% is a standard Windows env-var. If any program stores its settings in the standard location you can take advantage of the %APPDATA% env-var to make a script which isn't hardcoded to paths that may change by OS or username.
If the path to the settings folder is in the registry then a script could read that info, or you could just hardcode the path in the script. It's still something you would only need to edit if you changed usernames or machines, and in both those cases you would also need to re-supply the settings paths via the other method, so no disadvantage there as far as I can see.
[quote="xbprm"][quote="nudel"]
With the bottom script, if you reinstall a program or a computer you have to tell each installer where you want each program's config to be kept again.[/quote]
Yes, but how often do you reinstall windows from scratch? If you don't do it every day I think its worth it.[/quote]
Sure, but even if you don't, what is the disadvantage? The advantage, however small, is that you don't need to change anything when/if you reinstall software or move machines. If there's no disadvantage then you might as well go with the method that has the advantage.
The other much bigger advantage is that the longer script works with all software that stores its settings on disk. Very few programs let you configure where their settings are stored so writing a backup script which handles more cases seems an undeniable advantage to me.
[quote="xbprm"][quote="nudel"]
You only have to edit the top script if you start or stop using an application completely.[/quote]
Second script I do not have to change at all [/quote]
But you do still have to specify where the settings are stored in the installers of all your apps, if their installers even allow you do so. So the fact that you don't have to edit the second script does not mean there is less effort with that method. You've got to provide the same details, you just do it in different places with the two methods.
[quote="xpbrm"][quote="nudel"]
When you do edit it you provide the same amount of information as you would if an installer asked where you'd like the settings to be. (Though I admit it can take time to track down where a program stores its settings. So asking in the installer does add 'discoverability' which is definitely good. The installer could just say "this is where your settings are", though.).[/quote]
Not every program stores its settings in xml like DOpus does (Great feature for someone who likes to dig into settings like me)[/quote]
Indeed, but if a program doesn't store its settings in XML (or some kind of file on disk), you can't back up its settings using a file copy using either of the methods we're discussing, so that doesn't seem a pro or a con for either method.
That's a good point in general, but it doesn't apply to Opus. The important settings are in two easy to find directories: /dopusdata and /dopusglobaldata. The locations are different because some settings are per-user while others are per-machine.
I Repeat: I'm more than happy to discuss stuff that's actually likely to produce useful information, and it's relevant to using DOpus.
It's not a question of "ignoring a better way" ... the point is YOUR definition of "better way" does not necessarily coincide with someone else's -- that's true even if their only reason is "personal preference."
Yes! It's true, in the world of commercial software, "personal preference" is actually a legitimate reason for not liking something!
It's amazingly simple once you get the point.
You also seem to be assuming that anything that doesn't match your definition of "better way" must be supported by bad non-reasons. That would explain why you do not hesitate to say why something that works for you "seems undeniable advantage" ... as though "advantage to YOU" is all that counts.
This is just a bunch of crap. Because I don't feel like justifying my personal preferences to you, I am "pretending"?!
It's funny, you said you were leaving this meta-discussion, (the one that I asked be taken elsewhere a long time ago). Why are you continuing to add to the meta-convo with steaming piles of irrelevant ■■■■ like this? How do your off-topic guesses about whether I am "pretending" or not help me (or anyone else) learn more about DOpus? How is that "adding to the discussion?"
I Repeat: If you are truly astonished ... then I guess we simply don't see eye-to-eye on this specific issue.
Yes ... yes again, it seems like an advantage to YOU. Keyword: YOU. Even if "very few" apps do let you do this, some people may actually like the way the "very few" apps behave, and make a habit of preferring those "very few" apps over the "very many" apps that (in their opinion) get it wrong.
Not everyone just blindly follows the herd. Some people may actually like c:\perl. The "very few" people who do probably don't give a rat's ass whether you agree.
I Repeat: I will always prefer applications that don't enforce fixed assumptions about specific directories on the user's computer, over those that do. It's really just that simple.
This one is a real gem, you are the one who defines what people want via methods dictated by you? Not only that, they have to accept your kludgy workarounds as "advantages"?!
I don't think this thread is really very productive 
Feel free to continue in the coffee shop if desired...