Code::Blocks Forums
User forums => General (but related to Code::Blocks) => Topic started by: Kriz on April 07, 2008, 07:10:40 pm
-
Hi all!
First of all: Thanks for the new version of C::B! It's a real step forward compared against the former version and meanwhile it has become my favourite IDE when programming C/C++. Good work!
Now my two cents:
a) As a long time C/C++ programmer I've worked with several different IDEs including VC++ 6.0 SE, Dev-C++, Ajunta, KDevelop, C++Builder, Eclipse with C++ Plugin ect. One strange "problem" I encountered since C::B 1.0 was the blinking cursor behaviour when tabbing along a single line. I'm using 4 spaces tabs (real tabs are lousy) a lot and most of the time I cannot follow the blinking caret when tabbing. My wish for the editor caret is that blinking should be disabled if hitting the tab key repeatedly. For example have a look at Dev-C++ where the caret can always be followed with your eyes when tabbing.
b) The next wish is an improved syntax highlighting for documentation comments. Type /* and the parser recognizes the beginning of a normal multi line comment. Type /** and its style is changed to a documentation comment. So far this is ok, but if I want a normal multi line comment starting with a complete line of * characters it's still a documentation comment (/*********** ect.). The parser should be able to scan a definable number of * characters before choosing the right comment style. Let's say if I type /*** or /**** the syntax highlighting should switch back to the normal multi line comment style.
c) The last wish for improvements points to the "Multiple Selection" dialog when both Release and Debug mode are enabled. The two selection boxes should be marked by default, because it's really peeving to mark them manually again and again (even with the "Toggle All" button)...
Ok, that's all. It would be great if some day these three little problems will become history.
-
++ for point c).
It's easy to correct and quite a pain in the neck each time !
-
++ for point c).
It's easy to correct and quite a pain in the neck each time !
This has been discussed in other threads. I suspect that the reason it's the way it is is because developers have been using "Build Targets" in two different ways.
One way (the way I suspect you and I are both used to) is to specify compiler and linker options, such as "Debug", "Release", "Profile", "Optimized Debug", et al. Used this way, it would be very unusual that a file wouldn't be added to all build targets.
The other way, which I've seen the project for Code::Blocks itself use, is to treat Build Targets like sub-projects. Much like how projects within a workspace behave. So you would have Build Targets like "GUI", "Backend", "Networking", "Plugins", and so on. I'm not used to that, but I can see how with such a scheme you would almost always want to add a file to only one or two build targets. Although I don't know why this approach would be better than having several projects within a workspace.
I suspect the solution to make all parties happy would be to add a checkbox on that dialog specifying "Select all build targets by default". We could check that once and not worry about it again.
-
Drew: id give ya 50 brownie points if you submit a patch for that =-)
-
Drew: id give ya 50 brownie points if you submit a patch for that =-)
Brownie points, you say?
Hmm...I'm going to have to think of a way to do this elegantly.
- That dialog is a nice clean multi-purpose dialog used in several places, so I don't want to change it. Not to satisfy one use in one place.
- I could pop up a second dialog, asking if the user want all targets selected by default, but no. That would look clumsy and potentially irritating. Even if it only came up once.
- I could make it so that all targets would be selected by default if all targets were selected last time...but no. That could be confusing to some users and I'd be leaving the regulars on this forum to explain it to people until the end of time.
- I could stick this option checkbox on some other settings page...but where? I don't want to clutter up the interface, patricularly in a place that would be hard to find anyway. Is there a good settings dialog for this option to live in?
- I could derive a new dialog from that dialog and used the derived dialog-with-checkbox-option here. But that would add a new class and new files to the SDK. I'm not sure how the regular devs feel about that.
Let me sleep on it...
-
Thank you for considering our request.
I could derive a new dialog from that dialog and used the derived dialog-with-checkbox-option here. But that would add a new class and new files to the SDK. I'm not sure how the regular devs feel about that.
This would probably be the best option. But if it breaks something, forget it.
I could stick this option checkbox on some other settings page...but where? I don't want to clutter up the interface, patricularly in a place that would be hard to find anyway. Is there a good settings dialog for this option to live in?
You could add it in Settings>Environment>General settings thumb.
-
In my opinion we must save current selection for project. After first adding If user add new file in SAME project when in multi-target dialog he see his old selection. Maybe later I will implement this behavior for multi-target dialog.