The 29 May 2006 build is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 29 May 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060529_rev2513_win32.7z
  - Linux :
         http://download.berlios.de/codeblocks/CB_20060529_rev2513.deb (not yet)
         http://download.berlios.de/codeblocks/CB_20060529_rev2513_fc4+5.rpm


Resolved Fixed:

• Fixed issues with debugger breakpoints being screwed when adding/removing lines before them
• Fixed setting breakpoints for the correct file, if more than one projects are open and contain similarly named files (e.g. main.cpp)
• fix : don't ask to save project file due to 'internal' modifications/upgrading when running in batch build mode (note : a follow-up commit might be pending, but no panic it works)

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)
• there are several issues with Code Completion (is being redesigned : work in progress)

[Vampyre_Dark]

The title bar issue remains. C::B has been open ~15 minutes now, and still no icon in the title bar. (I just opened it in the background.

The program has an issue remembering the position and size of the window. When I click the maximize/windowize button, the program becomes a window, but it doesn't shrink to my last size from previous sessions, it remains @ 1024*768 and shifts over so half of the window is off the screen.  :?

[MortenMacFly]

The title bar issue remains. C::B has been open ~15 minutes now, and still no icon in the title bar. (I just opened it in the background.
The program has an issue remembering the position and size of the window. When I click the maximize/windowize button, the program becomes a window, but it doesn't shrink to my last size from previous sessions, it remains @ 1024*768 and shifts over so half of the window is off the screen.  :?

I cannot confirm both of these issues. Both works for me.
What OS are you using? Do you have a multimonitor environment? You really could give us some more details... ;-)
With regards, Morten.

[Vampyre_Dark]

Oops, I mean Startbar, not titlebar. Why did I type that? It was discussed before in a previous thread, but the issue there was that it didn't need to come up immediately. Which was fine. At the moment however, it doesn't come up at all until the app is focused.

1) Click C::B Shortcut
2) Click into another app that covered whole screen.
3) C::B never shows, must be ALT-TABBED into. It's like WX doesn't call ShowWindow() when it's done initializing.

I did more investigation on the other issue. C::B does remember the size and position. If I quit while maximized and then later reopen, I un-maximize to fullscreen window size at the old position. So my window gets shifted halway across the screen to the old position at the same dimensions it would be if maximized.

Incase that is not clear^^^

1) Make C::B a small window in the middle of screen. (Size and position remembered)
2) Later on, Maximize C::B (size recalled), and quit during normal usage.
3) Start C::B, it will be maximized like last time
4) Un-maximize the window, and it will be shifted to the position recalled at step 1, but at the fullscreen windowsize.

XP, 1 monitor.

[killerbot]

Oops, I mean Startbar, not titlebar. Why did I type that? It was discussed before in a previous thread, but the issue there was that it didn't need to come up immediately. Which was fine. At the moment however, it doesn't come up at all until the app is focused.

1) Click C::B Shortcut
2) Click into another app that covered whole screen.
3) C::B never shows, must be ALT-TABBED into. It's like WX doesn't call ShowWindow() when it's done initializing.

I did more investigation on the other issue. C::B does remember the size and position. If I quit while maximized and then later reopen, I un-maximize to fullscreen window size at the old position. So my window gets shifted halway across the screen to the old position at the same dimensions it would be if maximized.

Incase that is not clear^^^

1) Make C::B a small window in the middle of screen. (Size and position remembered)
2) Later on, Maximize C::B (size recalled), and quit during normal usage.
3) Start C::B, it will be maximized like last time
4) Un-maximize the window, and it will be shifted to the position recalled at step 1, but at the fullscreen windowsize.

XP, 1 monitor.

Today, I had the same problem, CB was started but I did not show up in the taskbar, alt-tab or minimizing all other apps was the only way to get in there.

[Conan Kudo]

What are the dependencies required by the binary RPM for Code::Blocks? (my machine is kinda slow on the yum update thing)
If there are any, is there a way to make it not require any dependencies, and will the release version have dependencies or will it be self contained?

[TheTuxKeeper]

What are the dependencies required by the binary RPM for Code::Blocks? (my machine is kinda slow on the yum update thing)
If there are any, is there a way to make it not require any dependencies, and will the release version have dependencies or will it be self contained?

The dependencies are:

• wxGTK >=2.6.2
• glibc >=2.3.6
• libgcc >=4.0.2
• libstdc++ >=4.0.2
• gtk2-devel 2.6.10 <- I don't know where this come from  :?  Shouldn't be the devel package. It's libgdk-x11-2.0.so.0 what's right (or not, why gtk ?). But usually *.so.0 links aren't in devel-packages, only the *.so links  :shock:  Will take a closer look at it when my exam is done tomorrow

The second question:
1.) I won't remove the dependencies because I'm not able to say whether the package works on other distris than FC4 and FC5. The glibc is one problem, the package is compiled against glibc 2.3.6 and don't work on much older versions (and older versions are usually used with an older gcc like 3.4 what makes it impossible to stay compatible). Removing the dependencies would cause a spate of questions why codeblocks doesn't even start and things like that.
2.) Make it self contained is no good way. This will mix up every package management the way it's used on linux (and other *nixes). Packages only contain things that really belong to them the rest are dependencies.

[Conan Kudo]

What are the dependencies required by the binary RPM for Code::Blocks? (my machine is kinda slow on the yum update thing)
If there are any, is there a way to make it not require any dependencies, and will the release version have dependencies or will it be self contained?

The dependencies are:

• wxGTK >=2.6.2
• glibc >=2.3.6
• libgcc >=4.0.2
• libstdc++ >=4.0.2
• gtk2-devel 2.6.10 <- I don't know where this come from  :?  Shouldn't be the devel package. It's libgdk-x11-2.0.so.0 what's right (or not, why gtk ?). But usually *.so.0 links aren't in devel-packages, only the *.so links  :shock:  Will take a closer look at it when my exam is done tomorrow

The second question:
1.) I won't remove the dependencies because I'm not able to say whether the package works on other distris than FC4 and FC5. The glibc is one problem, the package is compiled against glibc 2.3.6 and don't work on much older versions (and older versions are usually used with an older gcc like 3.4 what makes it impossible to stay compatible). Removing the dependencies would cause a spate of questions why codeblocks doesn't even start and things like that.
2.) Make it self contained is no good way. This will mix up every package management the way it's used on linux (and other *nixes). Packages only contain things that really belong to them the rest are dependencies.

Actually, I just wanted to make it self contained for my experiment:
Anywho... I made installers for Windows, Linux, and Mac OS X using one project file. And also, I forgot to statically link wxGTK :? so it only works on FC4 and FC5. If the experiment isn't a total failure, I will statically link it. I pulled C::B for Linux from your RPM for FC4+FC5 because I don't want to install all the devel packages yet.... A lot of pain and not a lot of space... And I'm pushing it right now... Also, if I messed the way I am supposed to package Mac OS X programs with an interactive GUI, then I am sorry. I have never built anything on Mac OS X because I do not have Mac OS X.... Sorry! And, I seem to hit a snag on GTK+ 2 and the Linux installer... It seems to be dropping to X mode instead of using GTK+ mode, but maybe that is just my machine.... I used Fedora Core 5 to build wxGTK2... That may mean something, I don't know..
Windows version: May 27, 2006 build
Linux version: May 27, 2006 build
Mac OS X version: rv2411 (don't know what day that one was built)
Anyways, here is the link: http://www.savefile.com/files/3782583

[TheTuxKeeper]

Nice

I'll try it out on my fedora installations, when I've got a bit more time. I'll give you a feedback

But I have to say that linking wxGTK statically doesn't solve the problem, because gtk2 has to be linked statically into wxGTK, too (don't know whether that's possible). Few days ago I updated from gtk+ 2.8.3 to 2.8.6 and few apps didn't start anymore because they didn't find some symbols. You see it's very complicated. The same will happen if statically linked wxGTK and installed gtk2 doesn't fit.

I don't know how your installer works (but I'll see when I'm testing it), but if it doesn't use the distri's package manager I won't be pleased with such a solution because using more than one package manager makes it extremly difficult to handle it.

But nevertheless IMO this installer a good idea

[Game_Ender]

If you aren't using Autopackage don't reinvent the wheel, AutoPackage seems to be the standard for most selfcontained linux packages.  It would be cool if CB had one.

[takeshimiya]

If you aren't using Autopackage don't reinvent the wheel, AutoPackage seems to be the standard for most selfcontained linux packages.  It would be cool if CB had one.

A klik package will be good too.

[Conan Kudo]

Nice

I'll try it out on my fedora installations, when I've got a bit more time. I'll give you a feedback

But I have to say that linking wxGTK statically doesn't solve the problem, because gtk2 has to be linked statically into wxGTK, too (don't know whether that's possible). Few days ago I updated from gtk+ 2.8.3 to 2.8.6 and few apps didn't start anymore because they didn't find some symbols. You see it's very complicated. The same will happen if statically linked wxGTK and installed gtk2 doesn't fit.

I don't know how your installer works (but I'll see when I'm testing it), but if it doesn't use the distri's package manager I won't be pleased with such a solution because using more than one package manager makes it extremly difficult to handle it.

But nevertheless IMO this installer a good idea

OK, well, my installer is kinda messed up, yesterday I discovered that I incorrectly set up the installation paths (I had ${installdir}/bin, etc.) and I need to figure out how to fix that. Also, I found out I forgot to activate RPM integration :oops: and so it won't register... Right now, I am busy fixing my site, I was hacked a few days ago, and I just repaired the MySQL database.... I will try to update the link in a few hours, but I cannot promise anything... Also, I need to statically link GTK+ also?!?! If all the distros already contain GTK+, I thought I just need to statically link GCC libs into wxGTK2 to make sure that I don't wind up with problems with OSes such as SUSE 9 and RH9.... These are eval versions, when I get it working perfectly, I will use the full OSS license I got a few days ago... Autopackage does not have RPM integration afaik...

[Conan Kudo]

Well, I finally got enough internet time to upload it...

I did not bother to update the actual Code::Blocks code, since this is an experiment and I am still trying to fix my development system to get Code::Blocks to build (symbolic links are turned dead with files existing)... So, here it is:

http://www.savefile.com/files/9291078

It has the Mac OS X, Linux, and Windows installers.... I don't know how to package the Mac OS X and Linux installers, but at least i packaged them... if you do not install as root, it will NOT register under RPM and will not install into root directories... Rather, it will install into $HOME/CodeBlocks by default...
I do not know why Code::Blocks refuses to launch, so I think there may be something wrong with the symbolic links...
Still, I did not statically link wxGTK2, so I do not know what may happen if C::B is run on something other than FC4/FC5...
If the Linux installer does not show a splash screen of C::B, then you will not be able to use C::B since it uses GTK+ 2 to start it... If GTK+ 2 is not installed, then it will default to X mode, which is baseline X GUI mode...
I DO NOT RECOMMEND RUNNING THE LINUX INSTALLER AS ROOT!!!