Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Will patches to compile and link C::B against wxWidgets 2.7.1 be accepted?
afb:
--- Quote from: stahta01 on November 02, 2006, 10:49:27 pm ---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.)
--- End quote ---
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:
--- Quote from: afb on November 04, 2006, 02:47:45 am ---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 ?
--- End quote ---
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:
--- Quote from: takeshi miya on November 02, 2006, 06:22:52 pm ---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),
--- End quote ---
Fixed, it was simple when using stdpath and wxStandardPathsBase:
http://www.algonet.se/~afb/wx/codeblocks-macconfpath.patch
Game_Ender:
--- Quote from: takeshi miya on November 02, 2006, 06:22:52 pm ---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,
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version