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

[Jenna]

On linux we still use config and user-data paths, that are not standard-conform.
These patches move the C::B config-files from "~/.codeblocks" to "~/.config/codeblocks" and the user-data from "~/.codeblocks/share" to "~/.local/share/codeblocks".
The "UserTemplates"-folders is kept in the config-folder, not in the user-data-folder. It's easier to use cross-platform this way (less "#ifdef"'s) and I'm not absolutely sure where they really belong.
The patch is not tested on Mac, but seems to work on windows.

I attach a 7zipped-file that includes 6 patches:
patch_1.diff ... patch_5.diff and an all-in-one patch (patch.diff).

The description of the patches:

patch_1.diff:
    - Do not use data_path_global for user-data when C::B starts in portable mode.
    It's not portable to have user-data in global-path and (what's more) the global-data-path is not user-writable on linux (and Mac?).
    Instead keep the user-data in the exe-path (as the config-files.

patch_2.diff:
    - BrowseTracker-plugin: use ConfigManager do determine the config-folder.
    It's better maintainable and should work correct after last commit.
    And it does not (try to) write the conf-file in the root-folder with new personalities.

patch_3.diff:
    - CodeSnippets-plugin: use ConfigManager do determine the config-folder.
    It's better maintainable and should work correct after last commit.

patch_4.diff:
    - DoxyBlocks-plugin: use ConfigManager do determine the config-folder.
    It's better maintainable and should work correct after last commit.
    And it does not (try to) write the conf-file in the root-folder with new personalities.

patch_5.diff:
    - Linux: Use standard-conform paths for config- and data-folders.
    Use glib to determine the paths, as wxWidgets still can not do this.
    All platforms: move UserTemplates into share/codeblocks to have the same layout on all platforms.
    The old config and usewr-data folders are moved to the correct place (after a hint).

The patches have to be applied in the correct order.
Alternatively you can use the all-in-one-patch.
The single patches might be used to inspect the changes more easily.

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.

[oBFusCATed]

Are there patches supposed to be applied with git am?

[Jenna]

Are there patches supposed to be applied with git am?

I never used git am and the patches are normal git diffs, but they are overworked with a script to make them (tortoise-)svn compatible.
That's why the git-part is at the top of the files.

[oBFusCATed]

OK... Is there any particular reason for using glib function instead of wxStandardPathsBase::GetDocumentsDir()?

[Jenna]

OK... Is there any particular reason for using glib function instead of wxStandardPathsBase::GetDocumentsDir()?

GetDocumentsDir() just returns the users home-folder.
If we use this we have to construct the complete folder-names ourselves.
The glib-functions return the correct paths directly and what's more, they should be aware of env-vars that change the default foldernames.
See: https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-config-dir and http://standards.freedesktop.org/basedir-spec/latest/ .

[oBFusCATed]

Are you sure?

I can see this code in the wx-28-branch:

Code

wxString wxStandardPathsBase::GetDocumentsDir() const
{
#if defined(__UNIX__) && !defined(__WXMAC__)
    {
        wxLogNull logNull;
        wxString homeDir = wxFileName::GetHomeDir();
        wxString configPath;
        if (wxGetenv(wxT("XDG_CONFIG_HOME")))
            configPath = wxGetenv(wxT("XDG_CONFIG_HOME"));
        else
            configPath = homeDir + wxT("/.config");
        wxString dirsFile = configPath + wxT("/user-dirs.dirs");
        if (wxFileExists(dirsFile))
        {
            wxTextFile textFile;
            if (textFile.Open(dirsFile))
            {
                size_t i;
                for (i = 0; i < textFile.GetLineCount(); i++)
                {
                    wxString line(textFile[i]);
                    int pos = line.Find(wxT("XDG_DOCUMENTS_DIR"));
                    if (pos != wxNOT_FOUND)
                    {
                        wxString value = line.AfterFirst(wxT('='));
                        value.Replace(wxT("$HOME"), homeDir);
                        value.Trim(true);
                        value.Trim(false);
                        if (!value.IsEmpty() && wxDirExists(value))
                            return value;
                        else
                            break;
                    }
                }
            }
        }
    }
#endif

    return wxFileName::GetHomeDir();
}

[Jenna]

I did not look into the sources, just the documentation:

wxStandardPaths::GetDocumentsDir

wxString GetDocumentsDir() const

Return the directory containing the current user's documents.

Example return values:

    Unix: ~ (the home directory)
    Windows: C:\Documents and Settings\username\Documents
    Mac: ~/Documents

This function is new since wxWidgets version 2.7.0

virtual wxString wxStandardPaths::GetDocumentsDir() const

Return the directory containing the current user's documents.

Example return values:

    Unix: ~ (the home directory)
    Windows: "C:\Documents and Settings\username\My Documents"
    Mac: ~/Documents

Since
    2.7.0

See Also
    GetAppDocumentsDir()

And that's what I find in the wx-svn sources:

Code

wxString wxStandardPathsBase::GetDocumentsDir() const
{
    return wxFileName::GetHomeDir();
}

[oBFusCATed]

It is this commit: https://github.com/wxWidgets/wxWidgets/commit/16dc7f88344eb640d9493963bfe9300556bd579b

After reading the code more thoroughly - I don't think it will be useful to us.
But still I think it is better not to depend on glib.

The spec seems to be pretty simple - http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
So it should not be hard to be implemented in a simple function.

[dmoore]

Wouldn't you want GetUserDataDir and GetUserConfigDir? Those are still wrong for Linux but are right in concept.

Agree with Obfuscated that it would be better not to have the dependency so how about a hand rolled version for now and file a bug request with wxWidgets for them to fix?

[Jenna]

Why not use/depend on glib ?
Just because the #ifdefs ?
We already have them, often because wxWidgets is (partially) not really cross-platform.
We also have dependencies on several other third-party libs, like e.g. gtk+ .

I agree, that it would probably be better to depend on just one toolkit (wxWidgets), but it does (obviously) not work.
We already have so many workarounds for wxWidgets drawbacks, that have to be manually fixed.

If I see, that the attempt to use xdg-compilant paths is from 2008, but seems to be removed again from sources, I don't see that it will be changed soon.
That means we need a workaround as long as it is not fixed.

And if we need a workaround, I prefer a workaround where I do not need to reinvent the wheel, if I can use existing (simly) functions.

I worked on this patche(es), because I got mails from other (linux) developpers and maintainers, that asked for more standard-compliancy.

Currrently I do not have the power or the time to work much on C::B, nor to discuss on wx-dev mailing list (I would work with new wxAui more in this case).
I do not see, if it will be better this year, there are private things I can not influence (and this might be the case for a long time, no one knows, sorry).

[oBFusCATed]

We also have dependencies on several other third-party libs, like e.g. gtk+ .

I think we will be able to drop this dependency when we switch to wx30.

I worked on this patche(es), because I got mails from other (linux) developpers and maintainers, that asked for more standard-compliancy.

I like the idea, so I'm not against the change.
I just don't like that we bring another dependency for just a simple function.

Currrently I do not have the power or the time to work much on C::B...

No problem with that, could you give me raw git patches, so I can continue your work?

[Jenna]

Changing the patches so we use self-contructed paths is not the problem.
The problem is to make sure it behaves correctly (checking env-vars etc.).
It can be done but it does not make sense and is probably error-prone (at least in some cases).
wxGTK already depends on glib, so it is not really a new dependency.

I have no time and power to bug the wx-devs to get it into wxGTK, the greatest problem here might be the backwards-compatibility.
All applications that use the existing functions would need to be overworked and that's something the wx-devs don't like most of the time.

And wx3.0 compatibility is still far away.

By the way:
I think we should drop the wx2.8 compatibility as soon as possible after moving to wx3, because the actual code is already cluttered with compatibility-ifdefs and hard to maintain therefore.

[oBFusCATed]

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.

I think we should drop the wx2.8 compatibility as soon as possible after moving to wx3, because the actual code is already cluttered with compatibility-ifdefs and hard to maintain therefore.

+1 here.

[oBFusCATed]

BTW:
I'm not really sure we should do the folder migration ourselves.
There are plenty of problems that might occur and the chance for data loss is not small.
For example I have symlinks in the ~/.codeblocks folder and I doubt the new code will handle them correctly.
Also running old and new versions might be problematic. I suppose, I'll add a ~/.codeblocks symlink for the first couple of months, just in case.

So, I'd rather prefer if C::B either:
1. exists with an error telling the user he/she must migrate the settings
2. just print a warning that the old location is used and urging the user to move them to the new location manually.

[frithjofh]

maybe write a one shot plugin which takes care of the appropriate changes for the user... (moving the config files and everything else necessary)

feel free to laugh or sneer at the proposal