Greetings!
I realise that, yes, I am a new comer and all, however, I have recently started using the Code::Blocks IDE because I am quite interested in getting a feel for the GPL software available.
First off, C::B has some really great things going for it, cross platform, integrated debugging, "compiler plugins" etc, I commend everyone who has put effort into this project, the product is definitely useful and as another comment said, an apt replacement for Visual Studio Users.
As a new user, possible quirks and, for lack of a better phrase, "UI design flaws" make themselves very well known. The overall general impression when taking a closer look is that the present UI has organically grown and it would appear as if things were sortof stuck on to the side of the original project.
The simplest example is the "Project" tab under the "Management" window. Adding new files to projects, and saving and loading different workspaces seems to be a very clunky excercise. Surely a workspace should correspond with say the Visual Studio Solution?
i.e. All projects are saved in a workspace, with a corresponding directory structure etc (the directories are debatable, but would you really want several related, but different program sources all shoved into one directory, ergo more automation) Further more, the default workspace should never be overwritten (except when you explcitly want to change your default environment, ie, the optoin shuold be tucked away) in my oppionion, a default workspace should be for those sandbox programs you want to code in 10 mins, and not worry about the overhead of a project and solution etc. thus it should perhaps be renamed the Sandbox workspace and always be accessable and not allow projects to be created in it, just thought of that now...
Also surely there should be some kind of consistancy when adding a project to a workspace and a file to a project?
i.e. To me it would make sense that when I right click on a workspace, it will give me an option to: add an existing project or new project, load\save\rename the workspace. These should all have analogs for projects in the workspace, eg add new\existing files to the project.
Also perhaps its just me, but the code tips and the code completion hasnt seemed to work so well for me :/
Sometimes it just doesnt pop up when calling for it (I have yet to see the code tip). I have noticed they seem to require a build I think, but it doesnt seem to link up nicely with header files :/ Maybe they need to be set up as the files are opened, and updated when the user has "finished" declaring the function\class\member\method etc.
I dont know if this is because they are tricky to implement or because noones actually done it right, or if im just being a straight up n00b
Also the compiler options interface. Once again, too much has been kind of stuck on the side. It took me a while to realise that there are workspace compiler options with separate options for each project. I would say this is related to the fact that a workspace isnt very well defined in C::B on the whole. I think the implication is that there should be a "Workspace" menu on the main menu, and in the same way the project properties has a button pointing to the build options, the build options should be unifed into a tree structure, so that essentially there is only "one" compiler options dialog.The current dialog for the compiler options, although at first seems nice, I get the feeling that it coudl really use some "ground up" redesigning. i.e. decide whats going to be more and less important, and make the more important stuff quicker to get to and the more obscure options a little more tucked away.
I know that some may think that I am just being fussy and anal, however, just think, this product is pretty close to a point where it could be used for full on commercial purposes, and im sure some companies out there do use it for just that. For this reason, I think its important then to consider the principles Industrial Psycology. In the work place you want as few things adding to stress as possible. For many people, clutter can create stress, therefore we want to avoid clutter whever possible. Arbitrary in-efficiencies and ambiguities that could "just be done better" can really raise blood pressure. If using an IDE becomes like driving in traffic, you arent going to want to use it, people want IDEs that are slim, effiecient, and that "Just Work". A well designed working environment, I would say, can have a dramatic improvement on a users morale. I have have found when using an application thats really intuitive that it makes me feel really chuffed. "Wow, check that out, this thing is like an extension of myself!"
As I said earlier, this is a really great project so far, and certainly the best if seen. I just get the impression that some more decisive action needs to be taken with respect to developing the UI. There shouldn't be multiple options that load the same dialog! (At least in unrelated areas, eg settings->compiler and project->compiler not to mention that those are both different to <right click>{project}->build options)
Im keen to see what others have to say, particularly those deeply involved in the UI. If need be I can even draft a "UI restructuring" so as to speak, and put it up for discussion...