Bjørn Roald wrote:
On 10/25/2010 01:44 PM, Stewart, Robert wrote:
Bjørn Roald wrote:
In any case I seriously think I may have missed points you have made in other posts. My statements was based om my understanding of the issue, and not a good understanding of all points made by others (including you) throughout this discussion.
OK. Please do try to account for all others have posted when writing or, at least, when another refers you to earlier arguments, have the courtesy to review the earlier posts to find the claimed arguments rather than expecting them to be reiterated.
Please stop this - this is not going anywhere. It is not that I did not read a lot before posting, I can not see where you got that impression from.
"I may have missed points you have made in other posts."
In this particular discussion I recall reading some of your posts in other threads on the subject of a portable "My Documents" folder concept. I just made the point that based on your reaction I thought there was a real chance I had missed something. It may also be the case that none of your arguments struck me as significant enough to make me change my position om the subject that a valid home directory is a fine solution on POSIX platforms. I do not intend to spend more time on this unless you point me to specifics.
Let me try making my points again, while incorporating subsequent ideas as well. My Documents is a default location for various kinds of documents. Windows users are notoriously naive because they come from so many walks of life, so it is common that everything be dumped in one place. Under earlier versions of Windows and DOS before that, users often dumped their files in the root directory of C:. Thus, My Documents is a way to force stupid^H^H^H^H^H^Hnaive users to dump their files in a less hazardous location. POSIX system users are typically less naive, though one reply mentioned the poster's wife as being in that class. Given the undesirable organizational results, choosing the home directory as the equivalent implies the need to find something better. To my way of thinking, one's home directory is very similar to C:\ on a Windows system -- not counting Vista and Win7, given their greater strictures on accessing the drive -- in that one usually puts little in the home directory and, instead, creates one or more arbitrary directories into which files are put. Now, with GUIs, there may well be an equivalent to My Documents, but only the applications written for that environment are likely to suggest it as a default location for saving a file. For example, running a GNOME app under KDE is likely to refer to the GNOME default rather than to the KDE default (assuming both have one). The foregoing suggests different locations for each GUI, plus arbitrary locations for other users. Now add the XDG stuff mentioned in another post and you have yet another variation for the location. Suppose you even try to account for the common GUI locations plus XDG. If you find more than one, which should be selected? Because of the above, the only common choice one can return on a POSIX system is the home directory and I find it a poor choice for a My Documents directory. Consequently, I'd rather Filesystem returned nothing than the home directory. Now, others have pointed out that most any location one would really want to use would be found under the home directory so, as a fallback, the home directory isn't so bad. Furthermore, it isn't Filesystem's job to babysit naive users; an application might choose to do something better. Does returning the home directory actually help provide portability? I don't think so. Given that Filesystem cannot decide among multiple choices when discovered (as described for multiple GUI equivalents plus XDG, all of which may exist), an application that calls a My Documents accessor won't know whether it is My Documents on a Windows system or the home directory to which some app-specific or vendor-specific subdirectory should be appended. Thus, I'd rather Filesystem return nothing when there is no obvious choice. Then, the application can learn that there is no path available from Filesystem, query for the home directory, and do the app-specific or vendor-specific work from that known point. If an application is written with generic portability in mind, then it would retrieve the home directory and add app-specific or vendor-specific subdirectories to locate the application-related documents, ignoring the My Documents directory on Windows. Such an app does not require an accessor for a My Documents type directory in Filesystem. My conclusion is that Filesystem should not provide a My Documents type directory unless there is an obviously good choice on the current system. IOW, it could include some complicated search for various environment-specific directories and, if there is a unique answer, return that but otherwise it should declare an ambiguity or failure to find an appropriate directory. Going back to my idea of calling a particular function to assert the desired convention, failure to find a conforming directory could result in creating the directory. It certainly would remove the decision Filesystem would otherwise be obliged to make of disambiguating among choices or forcing a potentially undesirable default. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.