Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

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

<< < (2/5) > >>

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();
}

--- End code ---

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

--- Quote from: http://docs.wxwidgets.org/2.8.12/wx_wxstandardpaths.html#wxstandardpathsgetdocumentsdir ---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
--- End quote ---


--- Quote from: http://docs.wxwidgets.org/3.0.2/classwx_standard_paths.html#aa87a172690af8f7535cc37f2e9b59c43 ---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()


--- End quote ---

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

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


--- End code ---

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).

Navigation

[0] Message Index

[#] Next page

[*] Previous page