Dear community,
on behalf of the whole code::Blocks team I would like to inform you hereby that we are in the preparation phase for a new release of Code::Blocks. Most important: WE NEED YOUR HELP!
The road map is as follows:
- the latest nightly (see http://forums.next.codeblocks.org/index.php/topic,12098.0.html) shall be the base revision
- from that nightly on we are on FEATURE FREEZE that means: don't expect / ask for new features, we won't commit such
- we expect bug reports, posted in an own thread in this forum: http://forums.next.codeblocks.org/index.php/board,7.0.html
- we will address critical patches with that release in SVN trunk
- if needed another nightly will be announced (you can call it release candidate if you like)
- a release branch will be created
- release will be done.
Here is what you can do:
- use the nightly proposed (or compile from trunk), report bugs!!!
- check the bug tracker of C::B for bugs still active that may be show stoppers
- if you are a developer: try to find patches for the bugs reported
Here is what you shouldn't do:
- ask for new features
- ask for a more detailed schedule
FINALLY: In addition I would hereby open a LOGO / SPLASH SCREEN CONTEST!
The rules are simple:
- setup a logo (probably based on the current one)
- post this logo in this forum: http://forums.next.codeblocks.org/index.php/board,7.0.html
- it must have our logo (as seen on http://www.codeblocks.org)
- the word "Code::Blocks" shall be part of the logo, including the "::"
- the word "Code::Blocks" should not be splitted
- there must be space for the release number (most likely 10/04)
- there must be space for the revision number
- it must "work" nicely under all platforms (important if you are using alpha / transparency)
- don't overdo it, we still strike for simplicity
- finally: discuss the logos, we will setup an open poll after a while to decide which one we will pick.
GO AHEAD! HELP US TODAY! :P
Edit: Added additional specification for the logo / splash screen contest
Glad to hear this news, thanks for all the hard works of your guys.
By the way, I still experience the time lags when I open the codeblocks.cbp.(even I disable the real-time options in CC), I suspect there are still something wrong. :(
Also, the split bar in the CC's symbol browser still can't be set correctly when startup (Windows XP), we have discussed here in this post:
Was the width of top view saved in CC configure file? (http://forums.next.codeblocks.org/index.php/topic,11870.msg80597.html#msg80597)
QuoteBy the way, I still experience the time lags when I open the codeblocks.cbp.(even I disable the real-time options in CC), I suspect there are still something wrong. Sad
I can confirm this: it's the problem I described here (http://forums.next.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521 (http://forums.next.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521)).
I remind you that Nightly Build 5911 doesn't show this behaviour.
Morten and others: Can you consider patch 002942 for inclusion in the this release?
There is at least on user that wants the "smart indent brace" feature to be off.
It might be that many don't know they need it :lol:
Quote from: MortenMacFly on March 10, 2010, 07:06:47 AM
FINALLY: In addition I would hereby open a LOGO CONTEST!
Isn't this a
Splash screen contest?
Quote from: vix on March 10, 2010, 05:16:52 PM
QuoteBy the way, I still experience the time lags when I open the codeblocks.cbp.(even I disable the real-time options in CC), I suspect there are still something wrong. Sad
I can confirm this: it's the problem I described here (http://forums.next.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521 (http://forums.next.codeblocks.org/index.php/topic,11790.msg80521.html#msg80521)).
I remind you that Nightly Build 5911 doesn't show this behaviour.
I'd still push for a new release. We can list this as a known bug just like CC can't do this / that... We can fix this bug and go for a minor release.
Quote from: Biplab on March 11, 2010, 07:47:18 AM
I'd still push for a new release. We can list this as a known bug just like CC can't do this / that... We can fix this bug and go for a minor release.
Agreed. In fact nobody can reproduce. I know what might cause this issue, but in fact it was a fix for another bug which is more likely to happen. And I have no clue why the current implementation shows such behaviour except that it's platform depended and/or might be caused by e.g. a silly AntiVirus software not allowing to create temporary files. I really doubt this is a bug in Code::Blocks.
Quote from: MortenMacFly on March 10, 2010, 07:06:47 AM
- post this logo in this forum: http://forums.next.codeblocks.org/index.php/board,7.0.html
So, should we each start a new thread for each logo submission? I might make a thread for all logo submissions if no one minds.
Quote from: MortenMacFly on March 10, 2010, 07:06:47 AM
- setup a logo (probably based on the current one)
- it must have our logo (as seen on http://www.codeblocks.org)
The above description is very confusing. It states, "Make a new logo, but it must have our logo." ...
Does this mean that we are designing a new logo, but we should use the existing "icon", which is the multi-colored block?
For example: Is this the kind of thing you are looking for? (http://blog.robotarcade.com/wp-content/uploads/2010/02/cblogo_custom1.jpg)
Hi, I hope somebody can fix this bug.
http://forums.next.codeblocks.org/index.php/topic,11847.0.html (http://forums.next.codeblocks.org/index.php/topic,11847.0.html)
Thanks!
Loaden: This seems like a feature request, so I think won't happen for this release....
A reminder: the CC bug fix of parsing the VC++ header file, see here:
Re: ParserTester for codecompletion plugin (http://forums.next.codeblocks.org/index.php/topic,12066.msg81956.html#msg81956)
I think it would be good to let the users grab the .blend file the logo comes from, in case they want to toy a little bit more with it. I was going to provide it, but it seems it is in a DVD I burnt which is now nearly 9000 km from here. Does anyone else have it?
[edit]
Nevermind: http://svn.berlios.de/wsvn/codeblocks/resources/block-logo/#_resources_block-logo_
[/edit]
[edit 2]
There is an idea that would be nice for the logo which we could borrow from Embarcadero. In Delphi, for example, in the splash screen you can see in very light colors, with different font sizes as well, reserved words of the language. We could use words like: class, virtual, public, private, operator, template, ...
[/edit 2]
Thanks for posting the Blender files.
I had to make an alternate version in order to center the logo and camera.
Here it is if it would be helpful to anyone: http://robotarcade.com/img/codeblocks/codeblocks_05.blend (http://robotarcade.com/img/codeblocks/codeblocks_05.blend)
In addition, this web site has some tasteful free/open-source fonts: http://www.theleagueofmoveabletype.com/ (http://www.theleagueofmoveabletype.com/)
1. Can this release fixed all bugs about "Internation".
there are some plugin's code confuse with "_" and "wxT".
2. "Open with HexEditor" is the lastone menu sub item of "File".
Pretty cool.
When you release the next official Code::Blocks version, I'll update my special plugin for it.
What does my plugin do? It allows you to create and test programs for a specific Prolog implementation.
Thank you and keep up the good work.
Quote from: code robot on March 12, 2010, 11:40:40 AM
For example: Is this the kind of thing you are looking for? (http://blog.robotarcade.com/wp-content/uploads/2010/02/cblogo_custom1.jpg)
Ok - the definition shall be:
"Design a startup/splash screen for Code::Blocks which contains the logo (the cube) and the writing "Code::Blocks", including the "::". Keep the cube basically as it is, but you can do position/resize it as you like (not too small, of course) and add some fancy surroundings as seen e.g. in the splash screen of 08/02."
I didn't expect the explanation needed to be that precise. Sorry, folks.
A short note concerning the logo contest:
Please post in a new thread in this forum, I'll set them sticky until we start a poll to find out the "winner". Notice that actually ANY contribution is welcome. We will keep all logos and designers in a record.
shall we contain the language files? and launchpad is obsolete
One simple question regarding the release:
Are you going to supply developers a "standard compiler bundle" and release at least one specific SDK for the same Code::Blocks build, wxWidgets and compiler versions? The wide diversity in compilers (MinGW official/TDM, MSVC, etc.) that users build their libraries with makes binary compatibility between an official C::B release and third-party plugin releases very difficult.
One example I can think of: the DoxyBlocks plugin is great, and the author released it as a binary (.cbplugin format) in sourceforge, but he compiled it against C::B svn 6182. I'm using Code::Blocks revision 6188. Thus, there is no practical way for me to get it running, unless I build both C::B and the plugin from source, everytime there is an update of either... And I'm not even going into the pain it is running the same plugin under Linux.
A definite choice of standard binary compatibility would encourage a lot more people to make their own plugins and share them as binaries.
Quote from: ptDev on March 18, 2010, 12:03:25 PM
A definite choice of standard binary compatibility would encourage a lot more people to make their own plugins and share them as binaries.
As with all other releases we will provide a SDK here, too. Plugin-Devs linking against that SDK will automatically be "compatible" with the release. However, if (for good reasons) we change the ABI for the
nightlies you cannot use plugins compiled against the nightlies version in the release version, obviously. To overcome, ask the devs to compile/link against the (fixed) release SDK.
Quote from: MortenMacFly on March 18, 2010, 12:21:15 PM
Quote from: ptDev on March 18, 2010, 12:03:25 PM
A definite choice of standard binary compatibility would encourage a lot more people to make their own plugins and share them as binaries.
As with all other releases we will provide a SDK here, too. Plugin-Devs linking against that SDK will automatically be "compatible" with the release. However, if (for good reasons) we change the ABI for the nightlies you cannot use plugins compiled against the nightlies version in the release version, obviously. To overcome, ask the devs to compile/link against the (fixed) release SDK.
Great! :D
Thank you for clarifying.
Quote from: MortenMacFly on March 15, 2010, 08:46:00 PM
A short note concerning the logo contest:
Please post in a new thread in this forum, I'll set them sticky until we start a poll to find out the "winner". Notice that actually ANY contribution is welcome. We will keep all logos and designers in a record.
By the way, I think it whill be good to fix code::blocks site`s URL in the final logo: http://www.codeblocks.org/ instead of http://www.codeblocks.org
Quote- it must have our logo (as seen on http://www.codeblocks.org)
i am terribly sorry for you to hear that, but your logo sucks .\
not really bad, but I(i repeat:
I) don't find it any attractive, but it's just my look on this.
here's a splash that i've made to replace default CB splash a pair of years ago:
// i've also replaced some default icons of CB, will you forgive me? .)
(http://s43.radikal.ru/i102/1003/ed/2b15a5e4df95.png)
don't mind the text labels, they have nothing to do with what i want to show you .D
of course this is not within the constraints of the splash contest, just showing what i'd like it to look like.
even years ago splash had png transparency, so why won't we use it fully?
and if you are not planning to pay any attention to the logotype look.. well, that's ok we will live with it)
(and replace, replace, replace... .D)
//added
codecompletion on svn 6088 seemed to go into infinite loop while parsing msvc9 header files
(on crtdefs.h, pre/post build steps (
rn "crtdefs.off" "crtdefs.h" and back) were my temporary solution.)
//last svn build(6181) always crashes on ctrl+f
//win7, don't have time to debug - deadline is near, will have to replace with hilight module.
- fixed: there previous svn
share\ files left when i renewed build.
removing files with old timestamp worked fine )
//added
well, sometimes i think that i wouldn't love coding that much if there wasn't such thing as codeblocks, even if i don't use most of it's modules (system win coding mostly, oGL gamedev least of the time), so here're some more gui bugs i want you to pay attention to .)
http://s44.radikal.ru/i104/1003/82/56c0ea7de649.png // they always got trunculated, maybe constant or user-defined window size will help?
http://i074.radikal.ru/1003/8b/e592553899e3.png // what a mess.. on win5 it shrank, on win7 it plays tricks with coder..
http://i078.radikal.ru/1003/de/943ab6394d09.png // "only 8.3 names allowed in this subsystem"? .D
http://i035.radikal.ru/1003/a1/c8d5a9871bbe.png // i don't know how to comment the obvious)
Hey guys, at last, a new release! I've been using the stable edition for some time now and it is a really convenient tool to work with Hmmm, splash screen...?
Please apply the patch to Code::Blocks or use MinGW GCC 3.4.5 for the release.
If not, please make a new version of exchndl.dll that works with the MinGW GCC used.
[ Patch #2780 ] Add code to build exchndl.dll to Core Project.
I have not tested the patch in several months.
Tim S.
Hey Tim,
could you explain why the dll that now is build with the nightlies is not ok ?
Quote from: killerbot on March 31, 2010, 07:57:57 AM
Hey Tim,
could you explain why the dll that now is build with the nightlies is not ok ?
The dll is involved in producing the crash report. Without the DLL matching the MiNGW GCC version the report is missing words/alpha and is just mainly numbers and shorter than it should be.
In other words the debug info format changed. It should work if the debug format was the same for DLL and MinGW GCC.
The compilers you used in the past was broken or used Dwarf2; I have not tried lately to see if the issue still exists.
Tim S.
Quote from: stahta01 on March 31, 2010, 04:08:22 PM
The compilers you used in the past was broken or used Dwarf2; I have not tried lately to see if the issue still exists.
Usually every MinGW/GCC compiler released ships with its own version of
exchndl.dll. So all you need to do is to use the same compiler for compiling wxWidgets and Code::Blocks and then ship the right version of the
exchndl.dll. I am aware that we have an old version in the repo which is compatible for MinGW 3.4.5 only. For the release we will should use the right one. But I don't think we really need to compile this ourselves...?! :shock:
I think you should copy the one that's coming with whatever compiler you use. Or, we should see if we can do without it (not quite sure what compiler flag would be needed for that).
If I remember correctly this DLL's sole purpose is to run some code at DLL_THREAD_ATTACH and DLL_THREAD_DETACH, which supposedly makes sure that heap memory allocated by exceptions is freed properly in multi-threaded contexts. Yeah, whatever :)
Exceptions should not happen very often anyway (hopefully), so I'm almost inclined to say "so what". I'm not even sure we throw anywhere at all, or whether that's heap-allocated.
Quote from: thomas on April 01, 2010, 10:06:54 AM
Exceptions should not happen very often anyway (hopefully), so I'm almost inclined to say "so what". I'm not even sure we throw anywhere at all, or whether that's heap-allocated.
Executing scripts can throw...
Quote from: MortenMacFly on April 01, 2010, 07:28:09 AM
Quote from: stahta01 on March 31, 2010, 04:08:22 PM
The compilers you used in the past was broken or used Dwarf2; I have not tried lately to see if the issue still exists.
Usually every MinGW/GCC compiler released ships with its own version of exchndl.dll. So all you need to do is to use the same compiler for compiling wxWidgets and Code::Blocks and then ship the right version of the exchndl.dll. I am aware that we have an old version in the repo which is compatible for MinGW 3.4.5 only. For the release we will should use the right one. But I don't think we really need to compile this ourselves...?! :shock:
I do not think so; it took days to find the source code for
exchndl.dll; maybe the next official MinGW release will have
exchndl.dll; but, I doubt it. This support of the source code seems to have been dropped.
Tim S.
I'm glad to see that a new stable version is going to be released.
Congrats to the developers!
When you open two or more projects and there are some variable or function with the same name across different projects, the "Find declaration of " feature will return the wrong location or "not found" message sometime, even after you close the all the other projects. It will become normal when you restart CB with only one project.
Quote from: ilcvm on April 07, 2010, 09:32:47 AM
When you open two or more projects and there are some variable or function with the same name across different projects, the "Find declaration of " feature will return the wrong location or "not found" message sometime, even after you close the all the other projects. It will become normal when you restart CB with only one project.
I guess this is an issue in CodeCompletion, but I have never meet this kind of problem.( because I always use only open one project at once :D).
When a project is closed, all the tokens belong to the closing project should be deleted. As in your case, these tokens were not deleted as expected, I think.
I seem to be having some trouble building the SVN version. I did a fresh "SVN update" last night, and still can't build because of some redefinition problem. I'm at work right now, but when I get home, I post the details.
I have wxWidgets 2.9.0
$> ./configure --with-wxdir=/home/Smitty/dev/sandbox/wxWidgets-2.9.0
Seems to work correctly.
Then
$> make
produces thismake[3]: Entering directory `/home/Smitty/dev/sandbox/codeblocks/src/base/tinyxml'
/bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../src/include -I/home/Smitty/dev/sandbox/wxWidgets-2.9.0/lib/wx/include/gtk2-unicode-release-2.9 -I/home/Smitty/dev/sandbox/wxWidgets-2.9.0/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../src/sdk/wxscintilla/include -I../../../src/include -I../../../src/include/tinyxml -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT tinywxuni.lo -MD -MP -MF .deps/tinywxuni.Tpo -c -o tinywxuni.lo tinywxuni.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../src/include -I/home/Smitty/dev/sandbox/wxWidgets-2.9.0/lib/wx/include/gtk2-unicode-release-2.9 -I/home/Smitty/dev/sandbox/wxWidgets-2.9.0/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../src/sdk/wxscintilla/include -I../../../src/include -I../../../src/include/tinyxml -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT tinywxuni.lo -MD -MP -MF .deps/tinywxuni.Tpo -c tinywxuni.cpp -fPIC -DPIC -o .libs/tinywxuni.o
In file included from ../../../src/include/sdk_common.h:96,
from ../../../src/include/sdk_precomp.h:14,
from tinywxuni.cpp:2:
../../../src/sdk/wxscintilla/include/wx/wxscintilla.h:2211: error: conflicting declaration 'typedef long int wxIntPtr'
/home/Smitty/dev/sandbox/wxWidgets-2.9.0/include/wx/defs.h:1110: error: 'wxIntPtr' has a previous declaration as 'typedef ssize_t wxIntPtr'
make[3]: *** [tinywxuni.lo] Error 1
make[3]: Leaving directory `/home/Smitty/dev/sandbox/codeblocks/src/base/tinyxml'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/Smitty/dev/sandbox/codeblocks/src/base'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Smitty/dev/sandbox/codeblocks/src'
make: *** [all-recursive] Error 1
This is Fedora 12 with all the latest updates.
Quote from: Smitty on April 07, 2010, 07:36:23 PM
I have wxWidgets 2.9.0
$> ./configure --with-wxdir=/home/Smitty/dev/sandbox/wxWidgets-2.9.0
Seems to work correctly.
Then
$> make
This is Fedora 12 with all the latest updates.
Please do not use this thread for wx2.9 issues. wxWidgets 2.9.x is a development branch; not a release grade product. Please start a thread somewhere else about this problem; note, the above error is sometimes an 64 bit problem so state your machine as 32 or 64 when you post; I suggest "General (but related to Code::Blocks)" sub-forum.
Tim S.
OK, I'll revert to the current stable wxWidgets.
Visual Studio 2010 has been released,can anyone here reveal the exact release date of C::B?hope it not far away^_^
Are we talking about a "stable" release (not a nightly build)? If so, this is really exciting. :mrgreen:
Keep up the good work, y'all! :D
Yes we are talking about "stable" release :)
This is a great news, after a long time without code, let's update our trunk and prepare to new release !
Thanks for all developers and testers :D
The 4th logo(cb_splash_2_jgm.jpg) seems much better than others and I wish it to be the champion :)
The C::B trunk doesn't compile without pch...
distro: gentoo ~amd64
Steps to reproduce
1. svn update to r6205
2. ./bootstrap
3. ./configure --disable-pch
4. make
make[3]: Leaving directory `/home/obfuscated/projects/codeblocks/trunk/src/sdk/resources'
make[3]: Entering directory `/home/obfuscated/projects/codeblocks/trunk/src/sdk'
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -fPIC -DPIC -fexceptions -MT projectfileoptionsdlg.lo -MD -MP -MF ".deps/projectfileoptionsdlg.Tpo" -c -o projectfileoptionsdlg.lo projectfileoptionsdlg.cpp; \
then mv -f ".deps/projectfileoptionsdlg.Tpo" ".deps/projectfileoptionsdlg.Plo"; else rm -f ".deps/projectfileoptionsdlg.Tpo"; exit 1; fi
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -fPIC -DPIC -fexceptions -MT projectfileoptionsdlg.lo -MD -MP -MF .deps/projectfileoptionsdlg.Tpo -c projectfileoptionsdlg.cpp -fPIC -DPIC -o .libs/projectfileoptionsdlg.o
projectfileoptionsdlg.cpp: In member function 'void ProjectFileOptionsDlg::FillGeneralProperties()':
projectfileoptionsdlg.cpp:350: error: invalid use of incomplete type 'struct wxSizer'
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of 'struct wxSizer'
projectfileoptionsdlg.cpp:357: error: invalid use of incomplete type 'struct wxSizer'
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of 'struct wxSizer'
Quote from: oBFusCATed on April 29, 2010, 02:28:09 PM
The C::B trunk doesn't compile without pch...
distro: gentoo ~amd64
Steps to reproduce
1. svn update to r6205
2. ./bootstrap
3. ./configure --disable-pch
4. make
Exactly the same here with the gentoo using live ebuild. It only compiles if pch enabled.
C::B svn rev:6215. Gcc-4.4.3. wxGTK-2.8.10.1. ~amd64.
projectfileoptionsdlg.cpp: In member function 'void ProjectFileOptionsDlg::FillGeneralProperties()':
projectfileoptionsdlg.cpp:350: error: invalid use of incomplete type 'struct wxSizer'
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of 'struct wxSizer'
projectfileoptionsdlg.cpp:357: error: invalid use of incomplete type 'struct wxSizer'
/usr/include/wx-2.8/wx/window.h:64: error: forward declaration of 'struct wxSizer'
make[3]: *** [projectfileoptionsdlg.lo] Error 1
make[3]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999/work/codeblocks-9999/src/sdk'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999/work/codeblocks-9999/src/sdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999/work/codeblocks-9999/src'
make: *** [all-recursive] Error 1
* ERROR: dev-util/codeblocks-9999 failed:Removing and installing wxGTK did not helped. Any idea?
could you update your svn (rev 6216) and try again
Well, is it still long till the new release?
Quote from: killerbot on May 08, 2010, 10:17:51 AM
could you update your svn (rev 6216) and try again
killerbot, many thanks for the fix. C::B compiles fine with svn (rev 6216).
Where can be found an up-to-date changelog of C::B ? I currently use svn 6206, I don't want to recompile if there is no changes which could interest me.
Thanks in advance. :)
Quote from: Folco on May 09, 2010, 03:29:51 PM
Where can be found an up-to-date changelog of C::B ? I currently use svn 6206, I don't want to recompile if there is no changes which could interest me.
Thanks in advance. :)
See my signature.
very curious if bugs such as resizing "build option" is fixed or not yet in this version.
Quote from: MortenMacFly on March 10, 2010, 07:06:47 AM
Dear community,
on behalf of the whole code::Blocks team I would like to inform you hereby that we are in the preparation phase for a new release of Code::Blocks. Most important: WE NEED YOUR HELP!
The road map is as follows:
- the latest nightly (see http://forums.next.codeblocks.org/index.php/topic,12098.0.html) shall be the base revision
- from that nightly on we are on FEATURE FREEZE that means: don't expect / ask for new features, we won't commit such
- we expect bug reports, posted in an own thread in this forum: http://forums.next.codeblocks.org/index.php/board,7.0.html
- we will address critical patches with that release in SVN trunk
- if needed another nightly will be announced (you can call it release candidate if you like)
- a release branch will be created
- release will be done.
Here is what you can do:
- use the nightly proposed (or compile from trunk), report bugs!!!
- check the bug tracker of C::B for bugs still active that may be show stoppers
- if you are a developer: try to find patches for the bugs reported
Here is what you shouldn't do:
- ask for new features
- ask for a more detailed schedule
FINALLY: In addition I would hereby open a LOGO / SPLASH SCREEN CONTEST!
The rules are simple:
- setup a logo (probably based on the current one)
- post this logo in this forum: http://forums.next.codeblocks.org/index.php/board,7.0.html
- it must have our logo (as seen on http://www.codeblocks.org)
- the word "Code::Blocks" shall be part of the logo, including the "::"
- the word "Code::Blocks" should not be splitted
- there must be space for the release number (most likely 10/04)
- there must be space for the revision number
- it must "work" nicely under all platforms (important if you are using alpha / transparency)
- don't overdo it, we still strike for simplicity
- finally: discuss the logos, we will setup an open poll after a while to decide which one we will pick.
GO AHEAD! HELP US TODAY! :P
Edit: Added additional specification for the logo / splash screen contest
Quote from: jens on May 09, 2010, 03:42:38 PM
Quote from: Folco on May 09, 2010, 03:29:51 PM
Where can be found an up-to-date changelog of C::B ? I currently use svn 6206, I don't want to recompile if there is no changes which could interest me.
Thanks in advance. :)
See my signature.
Indeed, but the changelog seems to have been refreshed until revision 6203, but not after this one. ^^
Quote from: Folco on May 10, 2010, 01:41:12 AM
Quote from: jens on May 09, 2010, 03:42:38 PM
Quote from: Folco on May 09, 2010, 03:29:51 PM
Where can be found an up-to-date changelog of C::B ? I currently use svn 6206, I don't want to recompile if there is no changes which could interest me.
Thanks in advance. :)
See my signature.
Indeed, but the changelog seems to have been refreshed until revision 6203, but not after this one. ^^
It's at actual revision.
Missing revision-numbers are commits in other branches than trunk.
Ok, thank you. :)
Quote from: eweb2009 on May 09, 2010, 09:55:04 PM
very curious if bugs such as resizing "build option" is fixed or not yet in this version.
Reposting an entire post from way back just to ask yet again a question that was replied elsewhere (that it apparently is an irreproducible bug) does not add much to the effort.
Just my 2 cents.
Ken
Why still not released?
Is the release dead?
Quote from: 198710 on May 21, 2010, 11:09:10 AM
Why still not released?
Is the release dead?
Check the log and don't spam the forums with such nonsense posts. Thank you.
I ask the question because someone said the release version in the logo is probably 10.04,but it's almost the end of May,OK?
Quote from: 198710 on May 22, 2010, 03:46:11 AM
I ask the question because someone said the release version in the logo is probably 10.04,but it's almost the end of May,OK?
We all want to release it quickly, but this is a difficult task. Please do not be too worried。
(http://forums.next.codeblocks.org/index.php?action=dlattach;topic=12441.0;attach=4597;image)
In the face of those blocks can not have some decoration? For example: print some light gray c + + code.
Quote from: nanyu on May 22, 2010, 08:11:22 AM
(http://forums.next.codeblocks.org/index.php?action=dlattach;topic=12441.0;attach=4597;image)
In the face of those blocks can not have some decoration? For example: print some light gray c + + code.
The bottom half of this new logo image is just "blank", I suggest adding some other information. :D
Is the new release already prepared?
codeblocks 10.05
download at here
http://download.berlios.de/codeblocks/
:D
Quote from: a14331990 on May 29, 2010, 10:35:47 AM
Is the new release already prepared?
codeblocks 10.05
download at here
http://download.berlios.de/codeblocks/
:D
I found these new release too. :D
it is already at the download position, just the final paperwork needs to be done. But please wait before downloading, it is always possible we encounter a last minute issue and we need to replace it ... ;-)