Will patches to compile and link C::B against wxWidgets 2.7.1 be accepted?

[afb]

Note: I am working on getting the patches ready for C::B for wxWidgets 2.7.0; I still testing changes for problems with 2.63p2, having issues with the SVN changing for the files I am patching. I have decided to break my patch into 4 (plus 1 for 2.7.1) small patches. ( 5 total files involved in all patches for 2.7.0 and 2 files for 2.7.1 for now.)

This doesn't look bad at all, actually! Rather small patches (good work!) Some of the patches could probably be made smaller by typedefs too, such as the int/uint confusion for instance ?

[stahta01]

This doesn't look bad at all, actually! Rather small patches (good work!) Some of the patches could probably be made smaller by typedefs too, such as the int/uint confusion for instance ?

I thought about using typedefs but was not sure if one was enough and if not one how many I should use.
Also, I would have to pick names and I had no idea what the C::B guidelines are on typedefs names.

PS: The wx2.7.1 compiles and links already (with my patches) but C::B has trouble with the "Setting" menu options "Enviroment", "Editor" and "Compiler and Debugger".

Tim S

[stahta01]

I have compiled C::B against wxWidgets 2.7.2 (CVS as of 1 hour ago.)

Tool bars icons and many others icons are NOT displayed; did not try the spots on the tool bars because I don't know which is where.

The only additional patch needed to compile current CVS is below:

plugins\compilergcc\compilergcc
Change
  wxFileName::CreateTempFileName(_T("cbmk"), 0L);
to
  wxFileName::CreateTempFileName(_T("cbmk"));


contrib plugins with compile issues against wxWidgets 2.7.2 (CVS-HEAD)
  C::B KeyBinder [This should be a minor patch.]

  Exporter see major method signature changes for class wxGIFDecoder in wx/gifdecod.h and src/common/gifdecod.cpp

  wxSmith [I have no plans to try to fix this, since a new version is under development.]

Tim S

[afb]

The first thing I found is that I couldn't run C::B because some previous setting in default.conf was bad,
and here comes the problem: the file is located in ~/.codeblocks, so I didn't have any way to access it (not from Finder nor terminal). I know that some programs let's you enable "see hidden files" but it's not the point and I didn't have one at hand,

I propose to use APPDATA as ~/Library/Application Support/CodeBlocks/ which is what most crossplatform/opensource programs are using (non-crossplatform programs tend to use ~/Library/Preferences because they don't have problems in using the plist format),

Fixed, it was simple when using stdpath and wxStandardPathsBase:
http://www.algonet.se/~afb/wx/codeblocks-macconfpath.patch

[Game_Ender]

The first thing I found is that I couldn't run C::B because some previous setting in default.conf was bad,
and here comes the problem: the file is locted in ~/.codeblocks, so I didn't have any way to access it (not from Finder nor terminal). I know that some programs let's you enable "see hidden files" but it's not the point and I didn't have one at hand,

While your point about the config location is correct I can't let you be this wrong.  I develop on the mac platform and terminal is perfectly capable of accessing "hidden" files.  Terminal.app is just a terminal emulator and it runs bash, tcsh, etc shells.  These access standard UNIX tools which have no problems manipulating "." files.

[takeshimiya]

While your point about the config location is correct I can't let you be this wrong.  I develop on the mac platform and terminal is perfectly capable of accessing "hidden" files.  Terminal.app is just a terminal emulator and it runs bash, tcsh, etc shells.  These access standard UNIX tools which have no problems manipulating "." files.

I know that, that's what I was referring with "some programs": you need bash/sh, you need to know which commands to issue like ls -a (which I didn't recall atm), and overall you're correct, those are standard UNIX tools, which I don't think a Mac user needs to know how to use, Finder should be enough in this case;
it was not the point anyways, and will now be fixed by the above patch.

[thomas]

Anders, are you sure those are the correct locations?

GetUserDataDir() and GetDataDir() both look like the top level folder, not the one owned by Code::Blocks. I think you may  have to add /codeblocks to both (unless wxMAC already adds the application name secretly).

[afb]

Anders, are you sure those are the correct locations?

Looked OK when I tried it (only tried the User one, but...)

the wx/stdpaths.h header said:

Code

    // return the directory for the user-dependent application data files
    //
    // $HOME/.appname under Unix,
    // c:\Documents and Settings\username\Application Data\appname under Windows
    // and ~/Library/Application Support/appname under Mac
    virtual wxString GetUserDataDir() const = 0;

[afb]

I know that, that's what I was referring with "some programs": you need bash/sh, you need to know which commands to issue like ls -a (which I didn't recall atm), and overall you're correct, those are standard UNIX tools, which I don't think a Mac user needs to know how to use, Finder should be enough in this case;

The wxWidgets libraries, like libwx_mac-2.6.dylib are not vieweable in the Finder or in Open either...
They usually install in "hidden" directories like /usr/local/{lib,include,bin} instead of "Mac" directories.

So for wxWidgets, we similarly need to change over to using a wxWidgets.framework bundle instead.
For now I am bundling the UNIX-style library with the C::B application, but that will move to external.

[thomas]

Anders, are you sure those are the correct locations?

Looked OK when I tried it (only tried the User one, but...)

Sorry, I pulled a Takeshi there. You're perfectly right, those two already append the application name.

Actually, after having read the documentation... you are not only right, you happened to find a much better implementation than the one we're using now, on all platforms. 

[Pecan]

While your point about the config location is correct I can't let you be this wrong.  I develop on the mac platform and terminal is perfectly capable of accessing "hidden" files.  Terminal.app is just a terminal emulator and it runs bash, tcsh, etc shells.  These access standard UNIX tools which have no problems manipulating "." files.

I know that, that's what I was referring with "some programs": you need bash/sh, you need to know which commands to issue like ls -a (which I didn't recall atm), and overall you're correct, those are standard UNIX tools, which I don't think a Mac user needs to know how to use, Finder should be enough in this case;
it was not the point anyways, and will now be fixed by the above patch.

I'm really surprised that a Mac programmer/developer is not expected to know how to use terminal and the minimum *nix commands.

I don't think I'd care to hire one of those.

[takeshimiya]

I'm really surprised that a Mac programmer/developer is not expected to know how to use terminal and the minimum *nix commands.

I don't know how you can ask this, since there are users in this forum that doesn't know even what a project is, or how to debug let alone where the problem was.
This is way off-topic too

[afb]

I'm really surprised that a Mac programmer/developer is not expected to know how to use terminal and the minimum *nix commands.

Not that surprising really, many Win programmers don't know this either (using Console and the minimum DOS commands).
And since the default Mac OS X file manager or the default file dialogs won't help them find the files, many users won't do so.

I would be surprised if the average UNIX/Linux developer didn't know it, but for Mac/Win I don't find it all that surprising ?

[thomas]

I've taken the opportunity to rewrite the directory stuff, using wxStandardPathsBase where possible and putting everything into a class that is kept as static instance in ConfigManager. That way, file paths are determined once per application, not once for every namespace (as it is now), and all the checks whether special paths exists are also only done once, instead of once for every namespace.

The only problem so far is that wxStandardPathsBase::GetUserDateDir() crashes on my machine... it seems to hit a null pointer inside AppendAppName(), humm....

[Der Meister]

Why are you using wxStandardPathsBase? The "standard" way should be like this:

Code

wxStandardPaths::Get().GetUserDataDir()

Anyway, I don't know if this fixes your crash, but I never had any problems with this line of code (not on Windows and not on Linux).