Emulator

isn't this a dupe of issue 177?

Konqueror may not set the working directory in the correct way so that dolphin-emu
can find the ./user directory. If trying to run the program that way doesn't work
now, then it definitely didn't work to run the program that way before I applied the
global build patch. In my opinion that is not a bug. If you use a global build that
problem will not occur, and I believe a global build should be the default. I don't
know of any program made for linux that makes a local build the default.

I think this whole "use the ./user directory first and fall back to ~/.dolphin-emu"
thing is not correct and should be removed from the program. I only put that in
because someone requested it. I don't understand this desire to have numerous ./user
(or ./User) directories hanging around. There are very few linux programs that allow
the user to choose a settings directory. This really makes very little sense in
almost all situations.

The only real issue I see is if we want to use ~/.dolphin-emu completely, or comply
with the XDG Freedesktop specifications.

Currently in Windows things are no different than before I applied the global build
patch. I am open to suggestions about how things should work there if those in
Windows want a global build, and can help to implement them, but I am really more
interested in the linux side of things.

If I am not mistaken, Mac OSX is using "~/Library/Application Support/Dolphin" except
for the no-gui build, which probably needs to be fixed to do the same.

As to the portable file...throw it out completely. It isn't doing anything useful on
any operating system. Here is its status since before I started working on the code:
On Mac OSX it was disabled. In windows and linux it was enabled but did nothing
useful at all. I mean analyze the code in Main.cpp that dealt with it. The whole
concept doesn't make sense. Someone told me it was put in to make file associations
work. What??? Again look at the code. It doesn't have anything to do with that.

XK: it might be, but is more specific to his patch right now. IMO its better to have
it separate for now, but we could block it on 177 since they are closely related (are
they?)

glenn: This was just based on my observations, if you believe this is correct (or
Konquerors fault), you can ignore it for now.
I usually run it either from command line or with gdb, so this issue never occurred
to me except the one time where i didnt.

The fallback is a sole suggestion of mine, if the majority is against it i wont
object. However, there might be (dev-)situations where you dont want this - i'd be
fine if we simply include a commandline switch that simply switches to ./User in a
hardcoded way.

I'm not really familiar with XDG, but the point with .cache does sound useful - but
is it worth the hassle? My Cache and ShaderCache folders are roughly 1 MB now...

Windows: it shouldnt be left outside if we do this for Linux and OSX already. Best
case solution would be SHGetFolderPath with CSIDL_PERSONAL (its in the code already,
but commented out - just needs some testing with the other folder id).

portable: kick it. Its initial purpose was something similar to your global patch,
but it failed epicly (which led to portable being default).

j4ck.fr0st: I was kind of guessing that you were thinking about the desire for a
local "./User" thing for developer testing situations. Currently on Mac OSX and
linux the program first checks for a ./User (mac) or ./user (linux) directory in the
current working directory, and then falls back to the standard location. It may not
work right if you run from a file browser, but most devs aren't going to do this. I
think this should be sufficient for devs to test for now.

Of course, I have been thinking of the user settings directory from the end user
perspective, which I feel should be as transparent as possible. Hence the stark
contrast in ideas on this matter.

I agree that Windows shouldn't be left out. I am the one that commented out the
SHGetFolderPath to keep things the way they are. Maybe sometime I will try to mess
with it.

One thing with the global build on linux in relation to the "portable" thing. If a
user that doesn't have administrative access wants to do a global build, they can
override the prefix to a directory they have write permissions for, and it will work
from there. For example, they could use "scons install=global prefix=$HOME/Dolphin
install". Then the user could add $HOME/Dolphin/bin to the path and run dolphin-emu
from any directory in a terminal, or double click on it from a file browser. It will
use the ~/.dolphin-emu settings directory and find all of the files it needs. This
is as portable as any linux program is expected to be. One thing that I would like
to add is a dolphin-emu.desktop file that is installed by scons to a location that
the desktop manager (Gnome or KDE) will find. This will add a menu item the user can
run the program from. I have done this in my PPA build for Ubuntu 9.10, and it works
quite nicely.

FYI, with current SVN global builds I do not get the "Trying to read from invalid SYSCONF" error message. Local builds do still give it, however, if dolphin is launched from outside its own installation directory, which forces it to attempt to use ~/.dolphin-emu rather than ./User.

Just wanted to provide an update, since it looks like this bug hasn't been specifically worked on in a while.

nitro322: This bug is closed. Or it should have been. With the local build, the intended way to run the program is from the directory it is build in. The global build will not have the problem. With the local build there is no way to determine where the plugins are if not run from that directory.

No problem. I found this bug several times in my searches related to this topic, and saw that it was (apparently) still open, so I just wanted to provide an update.

The global vs. local thing makes perfect sense. No complaints from me.

The local build should really just be for those that are developing and testing dolphin (and know how to work with it). The global build is really what is intended for the end user. I personally disable the ./user directory and use the ~/.dolphin-emu directory for all builds.

If that's the case, should global be made the default option? That way, developers (which are familiar with all the options) can throw in install=local for their own builds, but otherwise scons will do the right/expected thing for end-users with the default options?

I think you are falling into the usual confusion that many others that I have talked to have fallen into. An end user is not someone who compiles the program themselves. An end user is someone who downloads pre-compiled binaries for the particular operating system he/she is using.

That being said I agree with you that the global build should be the default to make it easier for those packaging for distributions, but I don't know if other dolphin developers agree.

I agree with global as the default.

Should this issue be closed now that global is the default?

One thing that has bugged me is the stupid "portable" file. That is only currently used at all on windows, and is utterly useless even there. We need to remove that file and the code in Main.cpp referring to it.

feel free to remove it I really doubt anyone is using the small feature it hackily provides. it saved the dolphin dir to a txt doc and when launching via doubleclicking a game in windows explorer would read the dolphin dir and change the working dir to it

lpfaint99: I see. I will let the windows devs decide on that.

I don't really mind what happens with it, but I'd keep it around until someone decides to fix Issue 3201 (unless you can remove it in a way that doesn't bother win32 until its fixed).

That makes sense.

cmake supports installing, and OSX allows you to just drop the bundle in the programs folder.