Linux patches review

[Air]

I think EXPORT_C() is win32-specific. It invokes Windows' automatic DLL-exporting semantics, so it's probably the preferred method to use for anything that's cross-platform.

[arcum42]

Generally speaking, anything with CALLBACK is older, and anything with EXPORT_C is newer. The main thing to keep in mind is that while they don't really do much in Linux, they are needed in Windows. (Also, I think the last time I decided to change everything to EXPORT_C, I was having trouble getting it to compile on both Linux and Windows, and scrapped it, so I'd be careful.)

(Oh, and of the null plugins, PADnull is the other one I wrote, btw. The rest were already there.)

[gregory]

Arcum,

Do not know if you had time to look at my previous XDG patch. But I clean it. I replace the C-C++ mix with Wx friendly code. It normally do the same.

[Air]

Do you know if wx2.9 and/or 3.0 implements XDG-compliant standard paths?

[gregory]

Good question.

Well a ticket is open (5 years ago): http://trac.wxwidgets.org/ticket/9300
And there is a commit related: http://trac.wxwidgets.org/changeset/53094 (it seems the same in 2.9 snapshot that I download).

The others important things is the default directory for main ini (usermode.ini). I changed it but I'm not sure it is correct. Not sure about the windows impact (aside from the first wizard after upgrade). But in linux, it move the ini file (from ~/.pcsx2) in the same default directory as others file (~/.config/pcsx2), better to have only one place.

[gregory]

Hum,

After reading the code. It is not exactely the same part of the specification. Wx return XDG_DOCUMENTS_DIR (actually not found it in the spec http://standards.freedesktop.org/basedir...01s03.html so I'm not sure of the purpose).
But for me it is the default directory for pdf or office files. There are simillar others default directory/variable (just found them ) : XDG_DESKTOP_DIR, XDG_DOWNLOAD_DIR, XDG_TEMPLATES_DIR, XDG_PUBLICSHARE_DIR, XDG_DOCUMENTS_DIR, XDG_MUSIC_DIR, XDG_PICTURES_DIR, XDG_VIDEOS_DIR

If I look at others applications they seems to use $XDG_CONFIG_HOME for configuration (ini) and $XDG_DATA_HOME for data (bios,logs and co). To be exact some application install some data also in XDG_CONFIG_HOME (probably to avoid the burden to handle 2 directories).

[Air]

The others important things is the default directory for main ini (usermode.ini). I changed it but I'm not sure it is correct. Not sure about the windows impact (aside from the first wizard after upgrade). But in linux, it move the ini file (from ~/.pcsx2) in the same default directory as others file (~/.config/pcsx2), better to have only one place.

Oh, yeah, that's not so good on windows. The userdocs dir doesn't even exist yet when the usermode.ini is created and/or loaded. On windows the usermode.ini is stored in an out-of-the-way area where apps store various data that's not really useful to users outside the context of the app. Currently it is optional for a user to create a /user/pcsx2 folder for their stuff. If I use it for usermode.ini, it'll be a mandatory addition to all user docs folders; even if a user would rather it in a subfolder or other better organized location.

I mean it's not a big thing, but it is typically a common courtesy for an app not to go cluttering up the user's docs folder with stuff unless it asks first.

[gregory]

Ok, make sense. I better understand the expected behavior.

One others idea that had in case multiple directories were needed. It is more clean in my opinion.
Just create a PathDefs::GetUserLocalDataDir() (or whatever the name) function that return wxStandardPaths::Get().GetUserLocalDataDir(). Then use the new function in the MiscPanelStuff and the AppInit. Purpose, all paths are in the same place and it is more easier to tune or change it.
In this case all user dirs will not be created, it is correct ?

About the dir settings on linux. Just to be sure we deal with the same definition (which I do not understand first )

Code:

WX                      |    linux                   | purpose
GetUserLocalDataDir    |    $HOME/.pcsx2       | configuration data. The usermode.ini. Just for information, with xdg stuff it is move to $HOME/.config/pcsx2. Directories that begin with a dot are hidden.

GetDocumentsDir         | $HOME/pcsx2           | user data.

The idea of the previous patch was to move the user data into the configuration directory in the default setup. Exactly for the reason you mention "not to go cluttering up the user folder", I just take it in the wrong way

[cottonvibes]

Initially I tried to keep a policy of leaving small functions in headers and leaving larger ones in CPP, but PCSX2's so large that it became overwhelming and was getting increasingly difficult for me to remember/decide if I should look for a function's implementation in a cpp or an h, and I frequently ended up with two problem cases:

1. a dozen or more functions of related action, some large and some small, and forced to decide if I should just axe the cpp altogether or axe the .h altogether (since having them split across 2 files were awkward).

2. forward declarations. Places where I have 2 classes inter-dependent on each other, so they'd still need to be fully defined in separate class declarations and method definitions (with implementations typically defined in .inl's, and then specially included after the .h's so that dependencies are properly resolved). This is actually a problem on MSVC, because it causes __forceinline to generate compiler errors. (sigh) So it would fix GCC inlining but break MSVC from even being able to compile.

my biggest complaint about c++ is the .h/.cpp separation of classes model.
its so annoying to separate class prototypes, and then have to implement them in another file; not only is it more painful to write the code, but its harder for others to look at and understand the code, especially when you have class member variables.
when you're looking at the .cpp file you have no idea what member variables are in your class and instead have to go back-and-forth referring to the headers to check.

because of these annoyances, i end up just implementing classes entirely in the header files. but this model has its own problem since it increases compilation time, and the compiler has to recompile everything referencing the header file whenever the header is modified. also probably bloats the executable.

i guess my approach should instead be:
implement simple classes entirely in headers, but split large classes up into .h and .cpp.

[Air]

because of these annoyances, i end up just implementing classes entirely in the header files. but this model has its own problem since it increases compilation time, and the compiler has to recompile everything referencing the header file whenever the header is modified. also probably bloats the executable.

Well the bigger problem is inter-dependent classes, which is what I run into more often. A contrived example is like this:

Code:

class joe
{
    Steve m_Steve;
    void SetSteve( const Steve& steve ) {
        m_Steve = steve;
    }
};

class Steve
{
    bool HaveSomeJoe( const Joe& joe ) const {
        // do something with Joe here.
        return joe.LikesBerries();
    }
};

Now Joe gets a compile error because Steve isn't defined yet. Swap classes around and Steve gets a compile error because Joe's not defined yet. This is the biggest limitation of C++: it's still basically a single-pass compiler in most ways. I run into that sort of thing enough that I'd just as well always do code/header separation. I tried to use two different coding styles for a while -- class/code together when possible and separate them only when dependencies occur -- but the number of times I had to separate was too often, and I decided I'd just prefer general uniformity over the occasional convenience of unified class/code.

The other big annoyance for me, and this might very well be fixed in VS 2010, is that code-in-headers breaks Intellisense much more frequently. When I was working on the DatabaseLoader for example, everytime I made any changes at all, I had to wait for Intellisense to update a bunch of crap before it'd work right again. Too many changes and the DB corrupted and it'd permanently lose some symbols. I almost never have that problem when working on anything else in PCSX2 (barring GSdx, which is also way too over-headerified).