Emulator

other shared files which aren't binaries are usually meant to go to /usr/share/dolphin

hi
config files should not be put in ~/.dolphin, but rather should follow the xdg
specification http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

basically: config files at $XDG_CONFIG_HOME
data files at $XDG_DATA_HOME
cache at $XDG_CACHE_HOME

is there anyone using that standard? I never saw those variables defined..

yes they do. if those variable arent defined the default locations are
~/.config/{app name}
~/.local/share/{app name}
~/.cache/{app name}
If you check out those folders, you will see various applications using them.
Applications are moving in that direction, with good newer applications especially
doing so. And freedesktop is the standards body we should be following

I suggest the following locations for installation:

Dolphin => /usr/bin/dolphin (lowercase!)
DolphinNoGUI => /usr/bin/dolphin-nogui
Libs/libwiiuse.so => --do not install, should be packaged separately by upstream--
Plugins/libPlugin_.so => /usr/lib/dolphin/plugins/.so
User/* => --$XDG_* stuff--

I'm not sure what {Sys,User}/{GC,Wii} are for.

In later versions, Dolphin should support multiple configuration files, so that a
global user config system could work. The Windows version would of course put its
user configuration data in the user's Application Data folder or somewhere alike.

• I like the capital letter, other programs sometimes use it as well
• the paths for binary/plugins/libs are obvious
• the paths of the things under Sys/User are the problem (including syncing of ini)
• I don't know of any advantage of using ~/.config or ~/.cache many applications
  don't follow the fd.o standard on that, and I don't think we should bother with it
  really.
  Just putting things under yet another subdir...

Is there some documentation about what each file in the Binary directory does? That'd
help ;)

Using the freedesktop config dir spec does have advantages for users. Config, data,
and cache are three logically distinct categories.

If I was now to just back up all my .* directories, I would end up with a huge amount
of wasted data, from picking up temporary caches and logs. All I probably want is my
config files and most importantly my (perhaps irreplaceable) data files which in this
case I guess would be save games. The spec lets me do this.

If I am using dolphin and break my config, I shouldnt have to browse into some folder
with a custom structure and work out what i need to delete to start a fresh, whilst
avoiding deleting data I can't get back. It should just be: go into .config, delete
dolphin, knowing that everything else is stored safely elsewhere.

If I wanted to synchronize my preferences between multiple computers, having to just
synchronize the .config folder would be a huge help

Please consider it

Anyone against adopting XDG?

I'd sure like to use it, I hate to have my home directory cluttered with dotfiles.
One directory should be enough.

Yea I am
too linux specific.....

Well how about this then:

• Windows: global conf in program's directory, local conf in Application Data or
  Local Settings or whatever. That, or current.
• Linux: XDG.
• Any other *nix: current or dotfiles (which could be just XDG with different default
  paths).
• Mac OS X: the above, unless someone knows what's "normal" for Mac OS X.

ini should probably be under /usr/share/dolphin I think
gnome xfce and vlc are all the programs I see using XDG are there more?

Or in ugly pseudocode:

--snip--

readable_data_homes is unset
writeable_data_home is unset
readable_config_homes is unset
writeable_config_home is unset

if ADHERE_XDG:
    if XDG_DATA_HOME is set:
        writeable_data_home = "$XDG_DATA_HOME/$DOLPHINROOT"
    else:
        writeable_data_home = "$HOME/.local/share/$DOLPHINROOT"

    if XDG_CONFIG_HOME is set:
        writeable_config_home = "$XDG_CONFIG_HOME/$DOLPHINROOT"
    else:
        writeable_config_home = "$HOME/.config/$DOLPHINROOT"

    if XDG_DATA_DIRS is set:
        readable_data_homes = map (++"/$DOLPHINROOT") (split ":" $XDG_DATA_DIRS)
    else:
        readable_data_homes = map (++"/$DOLPHINROOT") (split ":"

"/usr/local/share/:/usr/share/")

    if XDG_CONFIG_DIRS is set:
        readable_config_homes = map (++"/$DOLPHINROOT") (split ":" $XDG_CONFIG_DIRS)
    else:
        readable_config_homes = map (++"/$DOLPHINROOT") (split ":" "/etc/xdg")

elif ADHERE_DOTFILES:
    writeable_data_home = "$HOME/.$DOLPHINROOT"
    writeable_config_home = "$HOME/.$DOLPHINROOT"
    readable_data_homes = ["/var/lib/$DOLPHINROOT"]
    readable_config_homes = ["/etc/$DOLPHINROOT"]

elif ADHERE_WINDOWS:
    ### use Local Settings stuff...?

elif ADHERE_MACOSX:
    ### find out

else:
    ### PANIC: no path scheme set

--snip--

Note that DOLPHINROOT should be "dolphin-emu" or "dolphin" (I prefer the former,
because Dolphin is also a file browser from KDE 4), HOME is defined per POSIX, and
ADHERE_{XDG,DOTFILES,WINDOWS,MACOSX} would be boolean configuration variables that
will be set for the right platforms and build settings. For instance, if the platform
is Linux, ADHERE_XDG would be set by default. If this is implemented, then it would
be very nice to make this a SCons parameter (use_config_path_scheme= or
something shorter, but do use enums this time).

Also, /usr/share is not for things like (default) configuration files. That would be
/etc.

I strongly recommend using the LHS, even if you're running a non-Linux but still
POSIX-like system.

I meant FHS[1].

[1] http://www.pathname.com/fhs/

the ini are data files not configuration files
according to fHS we should use /var/cache:P
Fun that we have so many standards no one goes by;)

Dolphin.ini and nJoy.ini clearly are configuration files, so what ini files are you
talking about?

And could someone please give a clear summary for every file in Binary what it's for?
Without it, I wouldn't have a clue where to put which file...

from windows, but basically the same thing.... http://shawnh.arcynic.net/dolphin/filetree.txt

Thanks.

For Linux, I'd recommend the following:

• Adhere FHS.
• Adhere XDG.
• Using the name 'dolphin-emu' for Dolphin-specific directories, as the alternative
  may clash with KDE 4's thingy.
• Never, ever assume a filesystem is case-sensitive or not.
• Never, ever assume that $XDG_CONFIG_HOME and friends are all different.

So I've come to the following naming scheme:

• Application binaries go in /usr/bin:
  --- ./Dolphin => /usr/bin/Dolphin
  --- ./DolphinNoGUI => /usr/bin/DolphinNoGUI
• Libraries (including plugins) go in /usr/lib:
  --- ./Libs/* => /usr/lib/dolphin-emu/*
  --- ./Plugins/* => /usr/lib/dolphin-emu/plugins/*
• All log files should go in /var/log.
  --- ./exceptioninfo.txt => /var/log/dolphin-emu-$UID/exceptioninfo.txt
  --- ./User/Logs/* => /var/log/dolphin-emu-$UID/*
• All user-written data files (like states) should go in $XDG_DATA_HOME:
  --- ./User/GC/* => $XDG_DATA_HOME/dolphin-emu/GC/*
  --- ./User/SaveStates/* => $XDG_DATA_HOME/dolphin-emu/SaveStates/*
  --- ./User/Wii/* => $XDG_DATA_HOME/dolphin-emu/Wii/*
• User/GameConfig is static data, but should be overridable/expandable.
  --- ./User/GameConfig/.ini => /usr/share/dolphin-emu/GameConfig/.ini
• I guess their overrides/addenda should be just configuration:
  --- ./User/GameConfig/.ini => $XDG_CONFIG_HOME/dolphin-emu/GameConfig/.ini
• User/GameConfig/.txt is actually material for /usr/share/doc,
  as it only documents those files. Should be packaged as such,
  and probably need rewrites.
  --- ./User/GameConfig/.txt => /usr/share/doc/dolphin-emu/*.txt
• Cache should go in cache.
  --- ./User/Cache/* => $XDG_CACHE_HOME/dolphin-emu/cache
• Many other files are static data files:
  --- ./Sys/* => /usr/share/dolphin-emu/*
  --- ./User/Maps/* => /usr/share/dolphin-emu/maps/*
• Some other files are needed for (Linux) packaging too:
  --- $SVNROOT/license.txt => /usr/share/doc/dolphin-emu/LICENSE
  --- $SVNROOT/readme.txt => /usr/share/doc/dolphin-emu/README
• There is however also 'output-only' data, like screenshots and dumps.
  If you must have default paths for these (convenient for screenshots),
  these paths must be visible by default, since they can take up a lot
  of space:
  --- ./User/Dump/* => $HOME/dolphin-emu/dump/*
  --- ./User/ScreenShots/* => $HOME/dolphin-emu/screenshots/*

This limits the reach of Dolphin to the following directories:

• /usr/bin (app executables)
• /usr/lib/dolphin-emu (plugins, maybe other non-app executables)
• /usr/share/dolphin-emu (static data)
• /var/log/dolphin-emu-$UID (logs)
• $XDG_*_HOME/dolphin-emu (saves, states, config, cache, ...)
• $HOME/dolphin-emu/ (dumps, screenshots)
• /usr/share/doc/$PACKAGENAME (package documentation)

Also consider (non-)freeness, which is important for packaging at all. Are you sure
the binary files (ROM dumps, symbol maps, signature database, master key,
settings-*.txt) were legally obtained and can be distributed legally? Are you sure
they can be distributed under GNU GPL 2, as their sources aren't available? If not,
they must be spliced into a different, non-free package, and the free package should
depend on it.

This would give, for instance, the packages dolphin-emu (contrib), dolphin-emu-data
(non-free), dolphin-emu-plugins (free?).

/var/log has system log only not user one
why use .config if it clashes with kde stuff? great idea making everything into one dir
the doc files are not important and just a waste of space
I'm also not sure about the maps dumps and screenshots
You are welcome to ask debian-legal about what can gpled 2 and what not;)

• Where do you suggest putting user logs then? AFAIK, there is no standard for that... =/
• With 'may clash with KDE stuff' I meant we should never name any dirs just
  'dolphin', but 'dolphin-emu'. Also, using XDG ensures maintainability of user
  configuration, user data and user cache (too bad they didn't define anything for user
  logs :P), exactly as duncan.hawthorne explained in comment 9. Again, this could be a
  build configuration option for those who want to choose between $HOME/.dolphin-emu
  and $XDG_*_HOME/dolphin-emu.
• If the doc files can be removed, then please do so ;)
• To ask debian-legal about it, I'd need to know more about where exactly those dumps
  come from and, if relevant, what the end-user license agreement of the GC and Wii say
  about reverse engineering ;)

docs aren't going anywhere, emulation is powered by docs ;)

The dumps are not in the svn...

looks like another issue stalled by linux quibbling. hehe :)

https://build.opensuse.org/

Put this issue to an end... Please.

Dolphin will usually run standalone..

Why would it usually run standalone?
We are slowly getting there, it's just not high priority when we have sound/input/jit
problems on linux

Another thing to consider is to avoid bundling code. When building latest SVN I have
noticed that some things from the External dir are getting used, but I did not
investigate further. Details and rationale is given here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Does setup work for Linux as well? If so, we can close this issue

I am about ready to commit my global build patch. Before I do so I want to make sure
it works on all operating systems (i.e. doesn't break things on non-linux systems).
It does not satisfy all of the issues discussed in this thread, but at least it gives
the framework to build on.

A little explanation is needed. First, on windows and mac the build should be the
same. That is to say things will work the same as before for the end user. I have
tested the patch in windows, so really I am concerned about macs. If someone could
tell me the expected directory structure on macs that would help a lot.

Now for linux. Again, the default build will be the same. However, if you pass
scons "global_build=true" you will get a global build. The default directory
structure is:
/usr/bin/{Dolphin,dsptool}
/usr/lib/libwiiuse.so (and other general libs, although these should really be in
separate packages)
/usr/lib/dolphin-emu (Plugins directory)
/usr/share/dolphin-emu/{Sys,User}
(The default prefix is /usr, but you can change this by passing scons
"prefix=/usr/local" for example.)
Now as the the user's settings directory:
First the program will check in the current working directory for "./User". If this
directory exists, it will use that. If not it will fall back to a directory in the
user's home. The default for this is ".dolphin", although this can be changed, for
example, by passing scons "userdir=.config/dolphin-emu". If this directory does not
exist it will be created by the program, and the necessary files will be copied from
/usr/share/dolphin-emu/User.

The patch is attached, so test heavily please. As indicated by the filename, it
applies cleanly against svn r4988 (the latest at the time of this writing).

the binary name should be dolphin-emu, dsptool might also be a different package one
day.kde already got a binary called dolphin and we don't want to confuse people.
beside that what is in /usr/share/dolphin-emu? do we copy it to ~/. on first run?
do we update every revision?

It's nice that someone is finally working to solve this issue :)

Nakee: Changing the name of the binary is easy. I will do that.

Yeah, dsptool should probably go in another package, but that should probably be
taken care of by the package manager, not the scons install setup, unless the dsptool
code is taken from somewhere else.

The way I am setting it up, Sys and User will be installed to /usr/share/dolphin-emu.
That is the shared data of the program. The program will automatically copy files
from /usr/share/dolphin-emu/User to the actual user's setting directory if they are
missing. At this point the program just copy's missing files, but eventually and
hopefully it will detect the need to update files when necessary. I don't recommend
just overwriting files with new revisions, as this may overwrite files that the user
has modified. Perhaps a confirmation dialog would remedy this problem.

Oh, when I explained things earlier I forgot one important point. To actually
install the global build you need to give scons the "install" option. So to build
and install a global build the basic scons command is
"sudo scons global_build=true install"
(Of course the sudo is to obtain root write permissions to /usr, and on other linux
distributions you may need to obtain root permissions in a different way.)
The "install" option is only necessary if you are installing outside of the scons
build directory.

I also added a "destdir" option for scons that is for package building. For example
in my debian/rules file I use
"scons global_build=true destdir=$(CURDIR)/debian/dolphin-emu"
Note the "install" option is not needed here as the directory I use is inside the
scons build directory.

maybe install=global/local ? I think it's less confusing.
also I suggest using lower case for user and sys as well

Nakee: Should I make the executable be dolphin-emu for all builds or just for global
builds? Same for the lower case user and sys? For the executable this isn't to much
of a hassle but adds some annoyance to the scons build system. For the lower case
user and sys there it is much more of a hassle because changes also have to be made
to the code. Honestly I would prefer to make it always dolphin-emu, and always lower
case user and sys on linux (it is easy to leave it the way it is for mac and windows
with this).

What should I set the default user settings directory to be? Should it be .dolphin,
.dolphin-emu, or .config/dolphin-emu? This is configurable in scons, but which
should be the default option for scons?
Recall that the program will check the current working directory for a "./user" (note
the lower case) directory first and then use the default if that isn't found.

Here is a new patch. So now to do a global build use
"scons install=global"
I also dropped the global_prefix in favor of just using prefix. So to change the
prefix use "prefix=/usr/local" for example. Note that if you use the "prefix" option
without the "install=global" scons will effectively ignore it.
Also, the executable will now be "dolphin-emu", and "User" and "Sys" are now "user"
and "sys". These names are used in linux regardless of if you are doing a global
install. I am going to commit this patch to the svn tomorrow unless anyone objects.
Then we can continue to tweak it.

I think XDG is the right way ~/.config/dolphin-emu is the easy way:)
also cache directories should go under ~/.cache/dolphin-emu so it can easily be deleted.
And we need to make sure all directory names are lower case.
At some point I guess some of those directories should be user configurable from the
gui but I think we should ignore it for now:)

If we go with the XDG specifications and put the user settings in
~/.config/dolphin-emu and the cache dir in ~/.cache/dolphin-emu I think we should
remove scons option to configure the userdir. In fact if we go that way I think we
should just set it that way, and not have an option at all from scons, the gui, or
otherwise. That is aside from using a "./user" in the current working directory perhaps.
The reason I feel this way is mainly because this is the standard. Most programs
don't have an option for where to put a user settings directory. Why should dolphin
have that option?
In addition, with the current structure of the program gui configurability is not
really an option. You run into a catch 22 by trying to have the settings directory
configurable. The program needs the settings directory to get the settings, but it
needs the settings to get the location of the settings directory.
At one point I suggested a command line parameter, but that won't work with the
current structure either. By the time the command line parameters are checked the
program has already looked for and loaded several files from the users directory.

There are a few directories such as screenshot or dump directories users might want
to set differently. But I agree the less useless options the better lets just go
with xdg for now and see later if we need to add something more complicated.

Patch looks good so far, but there are some things that look odd (i only read the
diff, i didn't apply it yet):

• You defined a Reload method for the FileLogListener, but you didn't close the
  previous file (or do you even call that method?)
• I'd change userdir to a default of ".dolphin-emu", since .dolphin might be in use
  by the KDE filebrowser (didn't check, might be using something else)
• I'd merge the countless if install == global in the scons to one check with
  multiple assignments, more readable that way IMO.

I say start committing incrementally, so these patches don't become old.

I am applying the patch now as promised yesterday. We can build from what I have
done so far.

j4ck.fr0st: Yes, I defined the log listener without closing the previous file. So
that method is not safe to call in general and needs work. It should only be called
at this point if you are absolutely certain the log file has not been opened. I do
call that method in Main.cpp, but it is called only in the event that the logs
directory did not exist before. In that case it is impossible for the log file to
have been opened. In fact that is why I added that method. However, that method
should do a check to make certain.

I set the default in scons to be .dolphin-emu for now; however, it seems that there
is much disagreement as to the default location for the user directory. Many want
XDG specifications. It should not be hard to comply with that using the framework
that I have set up.

I think that if we want distributions to happily package dolphin we should go with
the XDG standard.