Standard conforms config- and userdata-paths - Patch(es) to test

[oBFusCATed]

Why do you think this will make a difference and make it less risky and error prone?  ;D

[dmoore]

Isn't a hand-rolled implementation as simple as:

Code Select Expand


wxString XDGUserData()
{
    wxString data_home;
    if (wxGetEnv(wxT("XDG_DATA_HOME"), data_home))
        return wxFileName(data_home, wxT("codeblocks")).GetFullPath();
    else
        return wxFileName(wxFileName::GetHomeDir(),wxT(".local/share/codeblocks")).GetFullPath();
}

wxString XDGUserConfig()
{
    wxString config_home;
    if (wxGetEnv(wxT("XDG_CONFIG_HOME"), config_home))
        return wxFileName(config_home, wxT("codeblocks")).GetFullPath();
    else
        return wxFileName(wxFileName::GetHomeDir(),wxT(".config/codeblocks")).GetFullPath();
}


Also, why in line 1475 of the unpatched code are we setting home_folder to the config dir?

Code Select Expand


void ConfigManager::InitPaths()
{
    ConfigManager::config_folder = ConfigManager::GetUserDataFolder();
    ConfigManager::home_folder = wxStandardPathsBase::Get().GetUserConfigDir();


What is home_folder supposed to mean? I guess it's not used anywhere but still...

[Jenna]

Also, why in line 1475 of the unpatched code are we setting home_folder to the config dir?

Code Select Expand


void ConfigManager::InitPaths()
{
    ConfigManager::config_folder = ConfigManager::GetUserDataFolder();
    ConfigManager::home_folder = wxStandardPathsBase::Get().GetUserConfigDir();


What is home_folder supposed to mean? I guess it's not used anywhere but still...

It's only used on windows in crashhandler.cpp in CrashHandlerSaveEditorFiles().

wxGTK already depends on glib, so it is not really a new dependency.

From the point of view of C::B it is abstracted away. If you want to go with the glib dependency, you'll have to change the spec file and probably the debian files.

Yes , I forgot these files. Even if it works, because glib2-devel is in the dependency-chain of wxGTK-devel (at least on Fedora), but this is , of course, not guaranteed.

[oBFusCATed]

Just tried it on my home dev machine, where I have symlinks in the .codeblocks folder.
It seems that it copies them as is, thus if there are relative symlinks then they are invalid after the copy, absolute symlinks work are not broken.
So everything works as expected.
I have no hard links so I don't know what happens with them. 

The way to fix old version compatibility is to create two symlinks:

Code Select Expand


ln -s ~/.config/codeblocks ~/.codeblocks
mkdir ~/.codeblocks/share
ln -s ~/.local/share/codeblocks ~/.codeblocks/share/codeblocks


p.s. probably the dialog message should be changed to something more formal and to remove the 'I' from it:)

[Jenna]

Hard links work (as far as I know they use the same inode and so they are neither relative or absolute), relative softlinks do not work.

[MortenMacFly]

Please test and give feedback, especially tests on Mac would be fine, because the the portable stuff has slightly changed: if the main config-file is found besides the executable, the user-data folder should always be there and not in the global-data-folder.

OK, so I've ran it some days now (Jens: The all-in-one-patch worked flawlessly) and so far I see no issues on Windows. Even better: The not portable files like dragscroll and the spellchecker stuff are now truly portable and work.

For the glib dependency: It was said already that wxGTK depends on it anyways... but besides to give my 2 cents: I thinks its not a big deal in this case because glib is not a "special" lib a user needs to install, its just there. At least that what I know from my (limited) Linux experience. If you take me as Linux "DAU" it works about of the box for the distros I use, so I am fine with it.

I see no issues applying it to trunk, therefore... for Windows... for Linux I let the hardcore Linuxer decide. But please think pragmatic... ;-)

[Jenna]

I just committed the changes with a slightly modified dialog-text.
I committed it with the glib2-depenency as glib2 is a dependency of wxWidgets and gtk2/3 itself and is installed on each linux-system, that runs C::B anyway.

"Reinventing the wheel" might sometimes make sense for time-critical functions (in fact it does not in many/most cases), but not here.
And using libraries should be in general less error-prone and easier to maintain, then to add new (linux only) functions to our sources.