Hmm. Ok, Nick, you have a point in that case, assuming you want to get that complicated. Under XP, Vista, etc. it would be the current user, under older ones, it would be the application path, since there is no "user" path. But that brings up another issue. Mainly, if you are going to put it in:
Win XP, etc. - Current User:/MUSHClient/
Win 98 < - /My Documents/
Then you need to either a) inform the user than the directory doesn't exist and ask if they want to create it *or* b) automatically create one. And if you really want to argue about that, then logically, on something like XP, the folder paths would have to be:
C:\Program Files\MUSHclient - main application and other support files.
C:\Documents and Settings\User_Name\MUSHclient\Worlds
C:\Documents and Settings\User_Name\MUSHclient\Plugins
C:\Documents and Settings\User_Name\MUSHclient\Logs
And so on. In any case, you have to make sure there is a directory to open/create something in at all. Frankly, for myself, I prefer to keep it where it is, even for XP, simply because if I change users I don't want to "lose" access to thing. But, if you really want to worry about that, then yes, any user data should be placed in the "users" data area, not in the program directory structure. That just opens a new can of worms though, especially if someone, like me, doesn't want it being put there and locked to a specific user account. In any case, the logical place for the data under older ones is "My Documents", but about 50% of the programs I know don't do that, and you still have the, "I am sorry, but the folder you are trying to put it in doesn't exist.", issue, not to mention that if you "do" put it in there you still need to make sure the name is unique, by doing what I show above and placing the files in "MUSHclient\Logs", not just "Logs".
It makes more logical sense in a way to do that (not that logic is high on the list of priorities for Windows software...), but it means adding checks for OS version, checks for user name on those that use them, checks for the existence of folders, code to create or request creation of them if they don't exist, and so on. And still installations only happen on those in the root system, you may also need to set up folders for "each" user that will use it, either at initial install or when each user runs it (the later being probably easier).
And no, the "document" directory should be unique and writable for each user. That isn't the same thing as the "startup" directory at all. Things like Word tend to remember the last place you opened/wrote something. The nicer ones remember each independently, so if you are doing something like image manipulation the "open" path doesn't mess with the "save" path. But they most certainly don't use, "where I currently am, according to the OS.", usually. The ones that do are imho, a major pain in the ass to use, since 90% of the time you have to navigate to what ever you are actually trying to do, even if 100% of the time the files you open with it are in the same place.
In any case, right now MUSHclient isn't XP aware. It has no clue that user profiles exist, that its running in one or that there is a document folder for that user. Its program directory ***is*** its document path, so its "startup" location is its own directory path. That means that at the moment its actually using "something else's" startup path/document path (depending on what the last application run was doing), when it tries to open a file, instead of its own. And that is where the problems are coming from. Word would break the same way if it used the path for some other program every time it did something, instead of remembering the last path you used *in it*, or using the path to the document you opened with it. That is the only case where the document path should change, if the document you open is some place other than where the program would normally look. And even then, unless you want to make plugins, logs, etc. sub paths to the worlds, those have their "own" document paths that are independent of the world files, in the current design.
Or to put it another way, you don't expect something like OpenOffice to look for word documents, spreadsheets and databases all in the "same" place you last opened a word document. You expect it to know that you last saved the word document in foo\bar, the last spreadsheet in foo\rab and the last database in foo\dbs, and not confuse those. But if you open something in foo\junk, you expect it to remember that "that" file is in foo\junk, and to not change directories on you, unless you do "Save As", and thus force it to forget the "foo\bar" location it normally starts in when opening files. Right now MUSHclient is doing the equivalent of starting in foo\bar, having something else start two seconds later in foo\me, and then trying to open its logs in foo\me instead of where *it* started. To use Word as an example, Word would **never** do this, nor would 90% of the other programs that exist. |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2 3
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top