I would wait, on the new wxWidgets blog, I could understand that wx 2.8 is very close !!Where did yuo find that information? I didn't read anything about that...
Maybe one or two more weeks.
Where did yuo find that information? I didn't read anything about that...
12th October 2006: wxWidgets 2.7.1 (a development release) is now available for download via http://www.wxwidgets.org/downloads.
The main changes since 2.7.0 are detailed below. We would be grateful for testing as we work towards 2.8.0 release within the next few weeks. However please be aware that 2.7.1 is not production quality.
One reason might be that wxExecute hangs on Mac OS X Intel
using wx 2.6.3, while it works just fine when using wx 2.7.1...
QuoteOne reason might be that wxExecute hangs on Mac OS X Intel
using wx 2.6.3, while it works just fine when using wx 2.7.1...
On second thought this is a lame reason. Might as well work
around the bug on wx 2.6.3, or wait until the 2.6.4 release...
Has this bug been confirmed that is a bug on wx 2.6.x ? I'm asking because I don't seem to have problems with wxExecute(), neither DialogBlocks which is compiled with wx 2.6.3 also I think, but it might be coincidence.
- Fixed non-detection of process termination on Intel Macs by
polling for process termination in a separate thread. because the next stable one will be 2.8.0, let's hope it's this week or next week
Do you have such a wxExecute demo I could try ?Not at hand unfortunately,
And it seem to coincide with this entry from the changelog:That's really great! Could you back-port the changes? I would be happy to have for the first time a C::B that can run programs on Carbon/Intel :D
BTW:AFAIK 2.7.2 is due to be released officially probably tomorrow (all wxAui classes will be renamed),
Why are there no more releases of the stable wxWidgets ?
OK, so why are there no more releases of the legacy wxWidgets then ? ;-)There might be a 2.6.4, but I don't think anytime soon, if ever.
Found the code in src/mac/corefoundation/utilsexc_cf.cpp.Yes it would be possible (cbExecute() or something like), however I prefer instead not wait for that and have a working C::B now, and at a later time, due to Tim patches use the 2.8 branch which contains lots and lots of improvements for Mac
They set up a background thread to poll for process termination.
Doesn't look impossible to backport, maybe we can even add it
as an add-on outside of patching the main wxWidgets library ?
Yup, that was it! I guess it could at least make it into a wx 2.6.3pl3,That's really great,
if there shouldn't be any more "real" 2.6 releases for some reason ?
Here it is, anyway:
http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch
On a third thought, we might not use wxExecute at all any more... :)QuoteOne reason might be that wxExecute hangs on Mac OS X IntelOn second thought this is a lame reason. Might as well work
using wx 2.6.3, while it works just fine when using wx 2.7.1...
around the bug on wx 2.6.3, or wait until the 2.6.4 release...
------------- Build: Debug in HelloWorld ---------------
Compiling: main.c
Linking console executable: ./HelloWorld
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warningsWorking on a new nightly build, will upload when finished.or .tar.bz2 / .dmg.bz2 as it compresses better, and .dmg would be for stable releases
(finally getting around to scripting thesuckerbuild process)
I will probably continue to use ZIP instead of DMG, though.
Something about open source and closed formats, I guess.
No changes to Code::Blocks were needed...:D
Patch submitted to the wx crew for consideration for wx 2.6.3pl3 / 2.6.4...So as you might have read, there are chances of a 2.6.4, but I'm waiting more for 2.8 :)
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1588883&group_id=9863
I have patched C::B SVN 3163 with my own patches enough to get it to compile, link and boot against wxWidgets 2.7.0:)
or .tar.bz2 / .dmg.bz2 as it compresses better, and .dmg would be for stable releases
13M CB_20061101_rev3164_macx86.tbz
14M CB_20061101_rev3164_macx86.zip
So as you might have read, there are chances of a 2.6.4, but I'm waiting more for 2.8 :)
Hardly worth the enormous processing time / memory usage difference, though.Strange, it usually gives a noticeable improvement; make sure you compress with "solid mode" ON or whatever is called,
13M CB_20061101_rev3164_macx86.tbz
14M CB_20061101_rev3164_macx86.zip
Especially not when considering that 50% of that is a redundant arch, and 60% is wx ?I think that's ok with stable releases, but for nightly builds and to save space I think that separating archs is better,
that's a bit sad, but this happens with most 'distros'QuoteSo as you might have read, there are chances of a 2.6.4, but I'm waiting more for 2.8 :)
I'm not holding my breath... Waited a month for the MacPorts guys to drop a single --with-mac line from the wxWidgets port (which isn't happening), so I'm on a build-it-myself streak.
Will fix the DarwinPorts version so that you can have both wxMac and wxGTK installed at the same time, which basically is just about doing up a Port for wxBase for them to share...
one last thing, can you upload a dmg to berlios? I can't wait to use it finally :D
Strange, it usually gives a noticeable improvement; make sure you compress with "solid mode" ON or whatever is called,
42M CB_20061101_rev3164_macx86.tar
18M CB_20061101_rev3164_macx86.tzo
14M CB_20061101_rev3164_macx86.tgz
13M CB_20061101_rev3164_macx86.tbz
14M CB_20061101_rev3164_macx86.zip
8.9M CB_20061101_rev3164_macx86.7z
I think that's ok with stable releases, but for nightly builds and to save space I think that separating archs is better,
about wx, only if it can be separated from C::B like windows' nightly builds (although it might confuse new users)
Here are the file sizes, for your amusement::lol:
42M CB_20061101_rev3164_macx86.tar
18M CB_20061101_rev3164_macx86.tzo
14M CB_20061101_rev3164_macx86.tgz
13M CB_20061101_rev3164_macx86.tbz
14M CB_20061101_rev3164_macx86.zip
8.9M CB_20061101_rev3164_macx86.7z
"Better" maybe, but it's not the Mac way... :-)There are apps out there that are bundle but separated by archs,
Hmm, the Xcode 2.4.1 (http://developer.apple.com/tools/xcode/) security update weighs in at.... 932.2MB.I think it's totally ok for stable releases but,
So I don't think 13M or 14M will make a difference to Mac users. :-D
There are apps out there that are bundle but separated by archs,
I think it's totally ok for stable releases but,
it's a bit too much for nightly builds, I don't know if you, but maybe other will be setting up nightly builds, this means everyday downloads,
and also accounting that berlios still doesn't support resume, there are people that still cares about the size, which are probably still on dial up or at a univ/work capped connection
6.3M codeblocks-1.0_0+macosx.i386.tgzThe down side is that we would have to make such a wx framework,Actual versions come with 2.5.x I think, and Leopard will come with 2.8 out of the box if nothing goes wrong,
and make sure that it is the right version and has the right patches...
There is no wxWidgets.framework. Tiger ships with wxPython 2.5 - as libraries.
I think that Leopard would be better off with wxPython 2.7 as libraries too, but...
The 3164 build is uploaded to BerliOS now
I prefer to use the cross-platform locations like /usr/local/lib/libwx_mac-2.6.dylib and ~/.codeblocks,Those are "unix" locations, in Windows you have them in C:\Program Files\CodeBlocks\wxmsw26u_gcc_cb.dll (usually) and %APPDATA%\codeblocks,
but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.frameworkIt's also fine as currently, if the mac dylib is inside the bundle,
I still suggest /Developer/Applications/CodeBlocks.app as the location for the program.Yeah, it's more standard than /Applications in this case and /Developer/Applications is more well suited (Xcode is there),
(that is, what used to be /usr/local/bin/codeblocks)I think that location can be fine if you build it from MacPorts, but /Developer/Applications is fine too,
Some of the wizards also needs to be redone to understand frameworks, such as the ones for OpenGL/GLUT and wxWidgets...Yes, there's a lot of work to be done
Those are "unix" locations, in Windows you have them in C:\Program Files\CodeBlocks\wxmsw26u_gcc_cb.dll (usually) and %APPDATA%\codeblocks,
in Mac I also like to have libraries in /usr/local/lib/ (because I use MacPorts), but for bundles (.app) it would be ugly to have them in /usr/local/bin and similar places.
but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.frameworkIt's also fine as currently, if the mac dylib is inside the bundle,
I still suggest /Developer/Applications/CodeBlocks.app as the location for the program.Yeah, it's more standard than /Applications in this case and /Developer/Applications is more well suited (Xcode is there),
however since C::B is distributed as a bundle, that's a users choice,
(that is, what used to be /usr/local/bin/codeblocks)I think that location can be fine if you build it from MacPorts, but /Developer/Applications is fine too,
Fair enough, let's move them to the Mac locations (I think wx has some helpers)Yes I know sorry for the copy-paste
MacPorts normally installs in /opt/local, though - but let's not mix that in here...
I had planned to separate it, in order to cut down the size of the nightly and also in order for the user to be able to develop new program for wxWidgets with it ?separated for nightly builds, joined for stable releases,
It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?of course,
MacPorts will install in /Applications/DarwinPorts and /opt/local, all according to their guidelines.I know, sorry for the copy-paste again; I wonder if the guidelines will change to MacPorts, I think /Applications/*Ports it's good nonetheless for the sake of symlinks, just when using MacPorts.
I had planned to separate it, in order to cut down the size of the nightly and also in order for the user to be able to develop new program for wxWidgets with it ?separated for nightly builds, joined for stable releases,
#include <wxWidgets/wxWidgets.h>It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?of course,
Yes. But that should be as simple as moving it inside the bundle, thankfully...Great
Will continue with the simple ZIP for a while, maybe convert to DMG for stable ?Or both, I have seen lots of .dmg.gz and .dmg.zip;
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 ?
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),
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.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;
Anders, are you sure those are the correct locations?
// 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;
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;
Sorry, I pulled a Takeshi there. You're perfectly right, those two already append the application name.Anders, are you sure those are the correct locations?Looked OK when I tried it (only tried the User one, but...)
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 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.
I'm really surprised that a Mac programmer/developer is not expected to know how to use terminal and the minimum *nix commands.
wxStandardPaths::Get().GetUserDataDir()
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'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 :P
Why are you using wxStandardPathsBase? The "standard" way should be like this:I sure was doing what you call the standard way :)CodeAnyway, 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).wxStandardPaths::Get().GetUserDataDir()
They are talking about releasing wxWidgets 2.7.2 on Friday, tomorrow, at 0900 GMT; I think this is 0400 EST. Edit: Person asked them to hold off till Monday so he/she could finish some task.
Note: I have given up on 2.7.1 because the docs have not been updated enough on wxDialog for me to figure out the changes in the wx27 code and how to patch C::B.
Edit: Found suggestion that pointed me in the correct direction to get 2.7.1 to compile & link.
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.)
Eventually launched with wxWidgets 2.7.2 on wxMac, after patching a couple of files. The wxAUI palettes are all blank, and some of the dialogs crash, but it did succceed to compile a link. We should get your wx 2.7 patches integrated with Code::Blocks as soon as possible to get ready for wxWidgets 2.8.0, I think.
Will upload the patches to BerliOS.
Note: A third way I used as testing work around was to -DwxHIDE_READONLY=0 with WXWIN_COMPATIBILITY_2_4 set to 0 in setup.h.
#if !WXWIN_COMPATIBILITY_2_4
#define wxHIDE_READONLY 0
#endif
wxAUI is now part of wx so we shouldn't need it (in the C::B sources) anymore if (and presumeably when) C::B switches to either 2.7 or 2.8.
Beside that, we have to wait for the thirdparty libs (wxScintilla amd wxPropGrid) to support the new version. That is nicer than patching those libs ourself.
Beside that, we have to wait for the thirdparty libs (wxScintilla amd wxPropGrid) to support the new version. That is nicer than patching those libs ourself.
wxPropGrid and wxScintilla already support wxWidgets2.7 - we use them in wxFormBuilder, which is built with wxWidgets2.7.
I just downloaded wxscintilla_1.69.2.tar.gz from wxcode on sf.net.Working with that one for a long time now under linux and windows... no problems.
I just updated wxPdfDocument to version 0.7.6, which is 2.7.x aware without breaking 2.6.x. The Source Exporter plugin compiled without problems, even though it generated a few warnings (type conversion and not-handled enums).
Please check if the new version compiles without problems with 2.7 so the patch 1626 can be closed.
Committing...
I think it is a good idea to make a packages that is available for people to test it. The more people test, the sooner we know if there to much trouble or not.I just downloaded wxscintilla_1.69.2.tar.gz from wxcode on sf.net.Working with that one for a long time now under linux and windows... no problems.
Anyway: A change of such a critical component as wxScintilla might have serious side-effects we don't know yet. That may be worse that the issues we are experiencing now. Please keep that in mind. Anyway - if more people just "testing" wxScintilla"++" - this would be helpful.
With regards, Morten.
I think it is a good idea to make a packages that is available for people to test it. The more people test, the sooner we know if there to much trouble or not.Mmmmmh... I cannot provide a package but maybe a patch against SVN trunk that has the new wxScintilla sources implemented. These are not only the new wxScintilla sources but also all patches we have applied to wxScintilla for compatibility... So I should provide 2 patches maybe: One for the new wxScintilla itself and one for C::B. I'll think about this...
I can create the package ;) But I can't compile :S There are some linker error with wxPropGrid... (I didn't try scintilla yet...)