Edit: Moved here from Using C::B forum, I accidentally put it there first
Hi,
I've started to use C::B as my main development ide a few days ago under ubuntu linux and i really like it. whenever i encounter a bug or think something could be improved, i "blog" about it in my personal tomboy notes. these are the notes from the last few days. because of the amount of them i've decided to put them all in a single topic to not spam the forum - sorry, i don't have the time to add single bug reports right now. this report is based on rev. 2447. i'm quite busy right now, but i'm going to help this project in the future.
1) all warnings are reported as errors. this is most probably because my gcc reports them in german. as long as there are no translations for c::b - perhaps this can be solved by using setlocale ("C") on startup?
EDIT: when i login with language POSIX instead of german all warnings are correctly recognized. then the wxScintilla widget shows all files that contain german special characters (umlaute (äöü) ) as if they were empty as mentioned in the other thread. hm. ok.
2) clicking on toolbar buttons several times is not possible. this is a problem when you want to click on a debugging function like "step to next line". you first have to move the mouse cursor away from the button before you can click it again. (yes, i know - everyone uses the keyboard shortcuts anyway
)
3) c::b should restore user input. e.g. if a SDL-program grabs the user input and crashes it is not possible to move the mouse cursor anymore. this is a gtk problem and might be avoided by using exception handling by the programmer, but it would be nice if c::b would handle it. that would also be useful for the debugger. if a breakpoint is hit, restore the user input to c::b. a plus would be to return the input to the program if continue is pressed.
4) implement a debug view that is automatically shown in the messages area at the bottom when the debugger runs. that windows ide does that fine. automatically show the callstack and watches next to each other.
EDIT: oh, that can already be done. anyway this should be implemented by default and there is room for improvement.
5) c::b should save all open files before compilation (well, i would also include project and workspace files so that they are not lost if the program crashes). sometimes it does save a file but i still haven't understood when and which files. btw. personally i would also save all project files and the workspace if the user clicks on save all files in the file menu.
6) while debugging, the current line should be about in the middle of the screen. if the current line is below a certain line after calling a debug function (e.g. step to next line), scroll the text so that it is in the middle again.
7) sometimes the text editor widget has no scrollbars or i can only see a 2 pixel line of the scrollbar on the right. sometimes "wild" resizing fixes this. eventually this is caused by the docking system - i got the impression that window sizes are not reported correctly.
8 ) the reason i did not use c::b for some time was mainly the drag and drop freezing problem. this has become a lot better but still occurs regularly. can anyone who knows what causes it create a small test program that shows the problem and submit it to the wxwidgets guys? that bug is really annoying
9) the current build target shouldn't be changed unless this is done by the user. sometimes when i click on build in the context menu of the project tree in a project other than the active one, the target changes from my desired one to "all" targets.
10) implement a context menue for the "targets tree" in build options that allows one to create and duplicate targets.
11) in the projects tree: show the same context menu if you click on "Sources" or "Headers" which is shown if you click on the project name.
12) "debug" and "release" targets with reasonable default options are needed for almost every project. is there a reason why you haven't included these? i have to admit that i only had a very small look at the targets of the c::b project itself. my first impression was that there were far too many targets and i couldn't see the advantage of creating a different target for every subproject. especially because that makes adding debug options a lot of work. well, this one might just be personal taste or i just haven't understood this.
13) although the correct filename and line of a build error is reported in the build messages, it is sometimes not possible to click on it to see the source code. i haven't checked this properly, but i've got the impression it happens if the error is not in a source of the active project (but it is in the current workspace) - linker errors also are often (or always? don't know) not clickable, though being reported correctly in the build message.
OK, that's enough for today
. i would be happy if someone adds a "fixed", "won't fix" or other info to a bug (will do that myself if something changes), but even happier if someone just fixes one of these
.
Bye,
Kai
