Author Topic: Code::Blocks could use restructuring and pruning  (Read 9859 times)

Offline Geoffles

  • Multiple posting newcomer
  • *
  • Posts: 12
Code::Blocks could use restructuring and pruning
« on: August 31, 2006, 07:13:46 pm »
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...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Code::Blocks could use restructuring and pruning
« Reply #1 on: August 31, 2006, 08:01:04 pm »
Quote
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...

It would help if you had mentioned what version of C::B you have based your judgements on. I get the impression you 're talking about 1.0rc2?
Be patient!
This bug will be fixed soon...

Offline Geoffles

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Code::Blocks could use restructuring and pruning
« Reply #2 on: August 31, 2006, 08:23:53 pm »
Ahh yes, my inexperience in these matters shows! Apologies

yes its 1.0rc2

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Code::Blocks could use restructuring and pruning
« Reply #3 on: August 31, 2006, 08:29:42 pm »
When you want to make constructive criticism of a project under development you should check out the most recent version, in this case that's the nightly builds which are linked to from the front page of the website.  Here is the link.  I think you will be pleasantly surprised.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Code::Blocks could use restructuring and pruning
« Reply #4 on: August 31, 2006, 08:34:06 pm »
yes its 1.0rc2

The difference of rc2 with the development version is measured in leaps ;).
And don't ask why so many differences between rc2 and what-will-become rc3. It will all be explained when we release it :).

EDIT: read this if you 're interested in evaluating the development version.
« Last Edit: August 31, 2006, 08:36:13 pm by mandrav »
Be patient!
This bug will be fixed soon...

Offline Geoffles

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Code::Blocks could use restructuring and pruning
« Reply #5 on: August 31, 2006, 08:43:01 pm »
hehe, ok great, ive been looking into the nightly builds, am d/l at the moment :D


Offline Geoffles

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Code::Blocks could use restructuring and pruning
« Reply #6 on: August 31, 2006, 09:55:32 pm »
ok, ive just had a look at this evenings build**, so im guessing its the very latest  :P

**This evening being the build from 30 august 2006

in a nutshell, heres my comments

Workspaces:
  • Work More like visual studio's Solutions(unless there is a different idea of what function exactly the workspace is supposed to perform)
    however, it would be nice to be able to save a workspace, in some or other location, which remebers the open files and stuff like that. That way, i could say just open a workspace from explorer, or open it directly from the front page and its just the way i left it
  • <Right click>add(or load) new\existing project
  • im guessing that the explicit activation of a project is for particular reasons, and i can see the value, but i think having a shift click or a quick button next to each project to activate would add a lot of value, especially if one is toying around with build each project or something, i have noticed the keyboard shortcuts, but thats still not the same, since you would need to cycle through them, and theres no mouse :P
  • As for the Idea of a sandbox workspace, i didnt go into it much before, but it would essentially be an isolated workspace, which allows the user to play with code a bit, this can be used as a handy debugging tool to say experiment in whatever language, the files would not need to be saved as per se (ie they would be entirely temporary). The core idea is a place where one can code, compile and execute without worrying about projects, whilst still having the benefit of a nice environment*, a sandbox :)

projects:
  • Really cool new project wizard, awesome directory structuring  and stuff
  • Like I said before, maybe an "add new file" would be nice, making it quicker to add files to a project

General layout stuff
  • I can see that a lot has changed with respect to the compiler menu and things, I would say a definite improvement!

Code completion
  • So far its looks much more comprehensive, still have trouble with it tho, but thats probably just me :)

On the whole I must say, the UI has a tremendous improvement over rc2, I am looking very forward to rc3 :) I guess i feel a bit silly for not looking at this sooner, but, i still think there are some useful ideas here, hope other people think so too!


*This is one reason why i like coding in linux, because Kate makes the perfect tool for that kind of thing, you can just spam a cpp file and code in there, and use the terminal tab to compile and execute, however it does lack the nifty extras you get from an IDE


Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Code::Blocks could use restructuring and pruning
« Reply #7 on: August 31, 2006, 10:22:40 pm »
Quote
projects:
Like I said before, maybe an "add new file" would be nice, making it quicker to add files to a project

I don't get this. "Project->Add files" and "Project->Add files recursively" don't suit you? They 're available both in the "Project" menu and when right-clicking on a project in the tree.

EDIT: oh, you mean create and add a new empty file? Yes, that functionality has been missing for some weeks now (was there, but vanished ;)). It will come back though.
Be patient!
This bug will be fixed soon...

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks could use restructuring and pruning
« Reply #8 on: August 31, 2006, 10:27:06 pm »
Quote
The core idea is a place where one can code, compile and execute without worrying about projects, whilst still having the benefit of a nice environment
Which certainly works in Code::Blocks, too.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

takeshimiya

  • Guest
Re: Code::Blocks could use restructuring and pruning
« Reply #9 on: August 31, 2006, 10:39:02 pm »
    • As for the Idea of a sandbox workspace, i didnt go into it much before, but it would essentially be an isolated workspace, which allows the user to play with code a bit, this can be used as a handy debugging tool to say experiment in whatever language, the files would not need to be saved as per se (ie they would be entirely temporary). The core idea is a place where one can code, compile and execute without worrying about projects, whilst still having the benefit of a nice environment*, a sandbox :)
    *This is one reason why i like coding in linux, because Kate makes the perfect tool for that kind of thing, you can just spam a cpp file and code in there, and use the terminal tab to compile and execute, however it does lack the nifty extras you get from an IDE
    Such feature already exists:

    Go to File->New->Empty file or File->New->File.
    Write your little code, save it somewhere, and you will not need to create any project, or whatever. :)

    Just go to Build->Compile current file (Ctrl-Shift-F9).

    EDIT: lol :lol:[/list]
    « Last Edit: August 31, 2006, 10:41:41 pm by Takeshi Miya »

    Offline Phatency

    • Multiple posting newcomer
    • *
    • Posts: 65
    Re: Code::Blocks could use restructuring and pruning
    « Reply #10 on: August 31, 2006, 10:41:51 pm »

    EDIT: oh, you mean create and add a new empty file? Yes, that functionality has been missing for some weeks now (was there, but vanished ;)). It will come back though.
    Hey, that's great news! We had a whole thread complaining about the current lack of that somewhere :e

    Offline Geoffles

    • Multiple posting newcomer
    • *
    • Posts: 12
    Re: Code::Blocks could use restructuring and pruning
    « Reply #11 on: September 08, 2006, 12:22:54 pm »
    I hear you about the compile file option, however, for instance just now i tried that on a c file (as opposed to a c++ file) and i couldnt find how to set the compiler to c rather than c++ , it just seemed to default it to c++. I think that that if you could create a full sandbox environment, where files dont even need to be save ot disk, it could add a lot of value, especially in terms of compiler options and such. Consider this scenario, you want to try out various preproccessor directives whilst working on your project, but you dont actually want to do it in your main project. My point is that you dont seem to have much control over the compiler by simply selecting compile file

    Offline tiwag

    • Developer
    • Lives here!
    • *****
    • Posts: 1196
    • sailing away ...
      • tiwag.cb
    Re: Code::Blocks could use restructuring and pruning
    « Reply #12 on: September 08, 2006, 01:17:12 pm »
    I hear you about the compile file option, however, for instance just now i tried that on a c file (as opposed to a c++ file) and i couldnt find how to set the compiler to c rather than c++ , it just seemed to default it to c++. I think that that if you could create a full sandbox environment, where files dont even need to be save ot disk, it could add a lot of value, especially in terms of compiler options and such. Consider this scenario, you want to try out various preproccessor directives whilst working on your project, but you dont actually want to do it in your main project. My point is that you dont seem to have much control over the compiler by simply selecting compile file

    you are wrong with all you've written ...  except your last point !

    1. just save your C file with extension .c and it will be compiled with gcc instead of using g++ (which is done for files with extension .cpp and a few others i guess)
    2. use java if you don't want to save files and use an interpreter
    3. if i want to test some compiler options outside of my main project, i simply create a test-target and do all my tests there

    4. that's the reason why projects should be set up in order to get detailled control over the whole build process,
       and there doesn't exist any other IDE out there, which makes it so easy to get everything under control, than Code::Blocks

    cheers, tiwag