Author Topic: Scripted wizards  (Read 17723 times)

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Scripted wizards
« on: October 10, 2006, 12:29:11 pm »
i do not like the scripted wizards as they are implemented now
and i'm really sad about, that the templated projects aren't supported any longer from scratch

though project-templates are availabale through the user-templates (please keep them)


the main problem which i have with the scripted wizards is the project-setup with debug and release targets.
in my opinion this is only suitable for small projects which are built of one target.

but in reality you need more often a project which consists of several targets,
think of a library, a library-test program, other libraries ... 
and an application which uses the libraries.

in such a case it is much better to organize the release & debug versions as projects

example of a real application workspace, which uses
e.g. a few open-source libraries lib1, lib2, and dll1

Workspace myapplication
*   Debug_project_unicode
      Target - lib1
      Target - test lib1
      Target - lib2
      Target - test lib2
      Target - dll1
      Target - test dll1
      Target - myapplication

*   Release_project_unicode
      Target - lib1
      Target - lib2
      Target - dll1
      Target - myapplication

*   Release_project_ansi
      Target - lib1
      Target - lib2
      Target - dll1
      Target - myapplication


one debug project for debugging and testing, two release projects for ansi and unicode.

what is *your* opinion ? any suggestions ?

takeshimiya

  • Guest
Re: Scripted wizards
« Reply #1 on: October 10, 2006, 01:01:05 pm »
The problem is that everyone uses differents layouts, for simple projects the "Release & Debug" project is enough, but complex projects requires complex layouts.
The good side is that you can modify the scripts to suit your specific layout needs.
The bad side is that with the previous templates it was a matter of editing a simple xml file, but now to accomplish the same you need to read and understand the scripts.
Not that they are difficult to understand, but it requires more time than before to do the same.

So it's a matter of simplicity vs. powerfullness.

A hybrid solution could bring best of both worlds: using xml for simple needs and generic pages, setting compiler flags, etc. and for projects that requires more than that, like creating new pages in xrc, etc, they'll need to create a script.

This will lower the barrier-entry for writting a template/wizard, keeping the best of before and now.


BTW, I never liked wizards of any type, they're bad performers in GOMS-KLM usability analysis, and this seems to be one of the reasons of why people still like the previous xml file-based templates.
In this case, instead of going trough a wizard every time you create a project, for enabling pch, for choosing the compiler, etc can be avoided and instead put in a single page, a "Setup" dialog for that kind of project.




Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: Scripted wizards
« Reply #2 on: October 10, 2006, 01:02:18 pm »
I prefer the way it is now.

Let's focus on a library which provides functionalities to be used by whomever (eg TinyXml) : It makes sense it has a debug build and a release build (debug : debug symbols, maybe some extra logging statements, non optimized; release : cut the crap and do it fast and small).
If the "tinyxml" project would not have these debug/release then every client has to create different targets of his 'program' to either get the library in debug or release dependeing on what he wants. Now he just creates his own (application) project (which also has debug/release) and makes his project dependent on that tinyxml project. Since debug/release is so common practice it's nearly some sort of defacto standard, and thanks to that dependencies between the targets work correctly.

Some IDE's even allow to change the configuration(debug/release) in the dependencies, say in your project you have a debug configuration but you never want that tinyxml library in debug because you trust it (and maybe the debug version is extremely slow), so they allow to even say in my debug "application" I want the dependency to be 'not on the default debug' but on the 'release' configuration.

The main difference it that the "project" view of things is different with what you described in your post.
You have :
  targets : lib, test app, the app
and everything sit's nicely together in the project file.

The view I talk about here is :
 project 1 : lib with 2 targets
 project 2 : the test app (with 2 targets)
 project 3 : the app (with 2 targets)
and everything sits together in the workspace.

I think both practices are ok, I prefer the latter one ;-)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Scripted wizards
« Reply #3 on: October 10, 2006, 01:15:38 pm »
tiwag, if I understand correctly, you 're only concerned about the "debug/release" page? If that's the case then all that's needed is a more elaborate page allowing you complete control over the targets to create.

I, too, understand that editing a script is not as simple as editing an XML file but you get infinitely more power with scripts.

And you, all, seem to have forgotten all the trouble we had with the XML templates. If you 'd like I could dig up a few relevant topics just to remind you ;)...
Be patient!
This bug will be fixed soon...

takeshimiya

  • Guest
Re: Scripted wizards
« Reply #4 on: October 10, 2006, 01:28:19 pm »
tiwag, if I understand correctly, you 're only concerned about the "debug/release" page? If that's the case then all that's needed is a more elaborate page allowing you complete control over the targets to create.
Yes that would be great. I can imagine a wxTree letting you choose the layout of the targets and projects.

I, too, understand that editing a script is not as simple as editing an XML file but you get infinitely more power with scripts.
I'm fine with scripts, they give power, and they are fine as long as user-templates (for when you're in a hurry) remains.

I still don't like the Wizard UI element, since everything can be placed in one dialog and you could edit everything in one-shoot.
But most IDEs seems to use Wizards (not that it's good), so on the good side, at least they will feel at home.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Scripted wizards
« Reply #5 on: October 10, 2006, 01:38:39 pm »
As you all might know I'm a "pro-script/wizard" guy. As Yiannis said: They simply offer more power. By translating the "old" templates into scripts the first thing I realised was: "Hey, you can do much more!". Sure: The current wizards could offer a lot more functionality - but they are just "a first step".
Allthough (IMHO) you already have all capabilities of designing a dialog that will add different compiler targets (I did this with a matlab wizard, see http://wiki.codeblocks.org/index.php?title=Scripting_commands for reference) I agree that the target setup could have another pre-defined wizard page to enable easier access. Anyway: I for myself like the Wizards more than templates. And if you disable all the entry dialogs they have the  amount of "work" for a proper project setup.
With regards, Morten.
« Last Edit: October 10, 2006, 01:54:34 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #6 on: October 10, 2006, 01:44:16 pm »
tiwag, if I understand correctly, you 're only concerned about the "debug/release" page? If that's the case then all that's needed is a more elaborate page allowing you complete control over the targets to create...
correct

i think we should not drive the users into a project-layout, which is inconvenient when it comes to extend the project
as it is with the "debug/release target" approach.

the problem which exists with that "debug/release target" project setup is,
that when you have several projects for building your application,
you have to take care of all needed settings (e.g. wx lib type, threading model, ...) to be the same in all projects
and you have to edit them manually for each project.

When you have a project-layout as i proposed in the first posting,
you start with a debug version and when the project reaches a state,
where you can think of a release version, you only copy the project file
and edit the debug and optimization flags and you can build your release
application without any other modifications.

With the "debug/release target" project setup, this is not easily possible,
until all targets in all projects have the same name (at this time no automatic check is possible)
and when it comes to build them in different object files folders, there is currently also the bug
in the CB- workspace-build-system.


Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Scripted wizards
« Reply #7 on: October 10, 2006, 01:47:04 pm »
I still don't like the Wizard UI element, since everything can be placed in one dialog and you could edit everything in one-shoot.
But most IDEs seems to use Wizards (not that it's good), so on the good side, at least they will feel at home.

That's just a matter of personal preference and I need no UI-guidelines/usability-tests to tell me if I like the look'n'feel of a dialog or not :).
Think of a newbie: is it easier for him/her to take the various options in small, grouped, chunks or present every little nitty-gritty detail in one dialog at once?
Besides, no-one is stopping you to create a wizard with just one page, effectively simulating the dialog you 're suggesting ;).
Be patient!
This bug will be fixed soon...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Scripted wizards
« Reply #8 on: October 10, 2006, 01:51:56 pm »
tiwag, if I understand correctly, you 're only concerned about the "debug/release" page? If that's the case then all that's needed is a more elaborate page allowing you complete control over the targets to create...
correct

i think we should not drive the users into a project-layout, which is inconvenient when it comes to extend the project
as it is with the "debug/release target" approach.

The reason this specific layout was chosen initially is because that's what most of the users coming from other IDEs (other than vim and emacs :P) expect to see. I never said it is the one and only approach to project layout. I think this is proven by the C::B project file itself ;).
Show some little patience and I will try to knock-up another, more powerful version of that page so scripts can have a choice which one to display.


there is currently also the bug in the CB- workspace-build-system.

I heard a rumour that it has been revamped and is waiting to be committed ;)
Be patient!
This bug will be fixed soon...

takeshimiya

  • Guest
Re: Scripted wizards
« Reply #9 on: October 10, 2006, 01:56:05 pm »
When you have a project-layout as i proposed in the first posting,
you start with a debug version and when the project reaches a state,
where you can think of a release version, you only copy the project file
and edit the debug and optimization flags and you can build your release
application without any other modifications.

With the "debug/release target" project setup, this is not easily possible,
until all targets in all projects have the same name (at this time no automatic check is possible)
and when it comes to build them in different object files folders, there is currently also the bug
in the CB- workspace-build-system.

I see what you mean about "targets" vs. "projects".
Indeed I do the same, but for my projects that use GCC, to use DMC and VC. To do that I change the little difference in flags with a sed script.

I think the problem here comes because C::B haves no notion of "configurations" or "properties", only of targets.
A "configuration" is only the difference in flags, thus instead of having a Release and Debug Target, you have one Target and a Release and Debug Configurations each one featuring the differences.


The good news is that this can be done using Build scripts ( http://wiki.codeblocks.org/index.php?title=Build_scripts ).  :)
The bad news is that you can read there "If you choose to go the build scripts way for your project, please don't use the project build options dialog (unless maybe for global project settings). If you do, things may not work as expected and you will unrightfully blame Code::Blocks for this ;)." :(



Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Scripted wizards
« Reply #10 on: October 10, 2006, 02:00:07 pm »
The bad news is that you can read there "If you choose to go the build scripts way for your project, please don't use the project build options dialog (unless maybe for global project settings). If you do, things may not work as expected and you will unrightfully blame Code::Blocks for this ;)." :(

Not wanting to sidetrack this topic but I wanted to give an answer to this.
Were you expecting to use build scripts and, at the same time, use the build options dialogs? You 're in for a mess if you do so :).
Note that C::B is not disallowing you to do so but rather makes you aware that things might not work as expected if you mix these two systems. You could use both if you know exactly what you 're doing though ;).
Be patient!
This bug will be fixed soon...

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #11 on: October 10, 2006, 02:04:14 pm »
The reason this specific layout was chosen initially is because that's what most of the users coming from other IDEs ... expect to see...
i hope we don't need to make the same failures than others did  :D

with my post i only wanted to start a discussion to point out the different possibilities of project-setup and their advantages and drawbacks.
i started with my point of view and am interested in the opinion of the proponents of the "debug/release targets" project setup.


there is currently also the bug in the CB- workspace-build-system.
I heard a rumour that it has been revamped and is waiting to be committed ;)
brilliant, thanks !

takeshimiya

  • Guest
Re: Scripted wizards
« Reply #12 on: October 10, 2006, 02:09:42 pm »
That's just a matter of personal preference and I need no UI-guidelines/usability-tests to tell me if I like the look'n'feel of a dialog or not :).
Hehe, I'm not talking about look'n'feel of a dialog, but about the time and steps you have to spent to create a new project.

Think of a newbie: is it easier for him/her to take the various options in small, grouped, chunks or present every little nitty-gritty detail in one dialog at once?
Yes that's true, that's why I said that they'll feel at home.
In short: wizards are good for newbies and non-tech-savvy users. But otherwise, they are not the best for power-users or programmers and so is revealed with a simple GOMS-KLM analysis.

What I'm saying is that instead of a "Go" button for the wizards, use two, a "Create" button which will create the project instantly and a "Setup" button which will let you choose the paths, configurations and whatever, which rarely changes each time you create a project.

Besides, no-one is stopping you to create a wizard with just one page, effectively simulating the dialog you 're suggesting ;).
Of course nothing stops no-one, but we have to discuss things first, right? If not, one could do a wizard in one way and another person in other way. And consistency would be lost.

takeshimiya

  • Guest
Re: Scripted wizards
« Reply #13 on: October 10, 2006, 02:14:24 pm »
Note that C::B is not disallowing you to do so but rather makes you aware that things might not work as expected if you mix these two systems. You could use both if you know exactly what you 're doing though ;).
I though it could be plagged with bugs and crashes so I feared :P
So that's good news, I can ditch the sed scripts in favor of the build scripts :D

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Scripted wizards
« Reply #14 on: October 10, 2006, 02:19:22 pm »
Note that C::B is not disallowing you to do so but rather makes you aware that things might not work as expected if you mix these two systems. You could use both if you know exactly what you 're doing though ;).
I though it could be plagged with bugs and crashes so I feared :P
So that's good news, I can ditch the sed scripts in favor of the build scripts :D

Make sure you post any bugs you find, as the usage of both systems (concurrently) hasn't been tested ;)
Be patient!
This bug will be fixed soon...

takeshimiya

  • Guest
Re: Scripted wizards
« Reply #15 on: October 10, 2006, 02:23:33 pm »
Make sure you post any bugs you find, as the usage of both systems (concurrently) hasn't been tested ;)
Will do so. :)

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #16 on: October 10, 2006, 03:20:30 pm »
i'm really amazed about the fact, that nobody is arguing pro the CB versatile Project & Target build system.

in my opinion it is one of the killer-arguments, why to use CB.
Project & Target setup is so easy and at the same time so powerful compared to all other free- / open-source IDE's.

instead of pushing and explaining this powerful tool to new users,
there are only ideas to "hide" it behind a Debug and a Release Target in every project ?

i'm reallly amazed about  :P

sethjackson

  • Guest
Re: Scripted wizards
« Reply #17 on: October 13, 2006, 07:32:49 pm »
Well I like the wizards, BUT I don't like the Debug, Release target in every project. I generally just tell C::B to create one release target (which I rename to default). Then I have to go turn off the optimization switches and stuff....

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Scripted wizards
« Reply #18 on: October 13, 2006, 07:38:57 pm »
Well I like the wizards, BUT I don't like the Debug, Release target [...]
What I personally don't get from this discussion: The Debug/Release target page is only a template. You can have any page there and you can setup a project with a scripted wizard as you like. You are not limited by the scripted wizard to release/target, only if you use a wizard that is limited to this kind of targets. Seth: You should know that...?!
My suggestion is instead of again and again discussing this topic why not trying to implement what is required for the individual?
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #19 on: October 13, 2006, 08:02:04 pm »
Well I like the wizards, BUT I don't like the Debug, Release target [...]
What I personally don't get from this discussion: The Debug/Release target page is only a template. You can have any page there and you can setup a project with a scripted wizard as you like. You are not limited by the scripted wizard to release/target, only if you use a wizard that is limited to this kind of targets. Seth: You should know that...?!
My suggestion is instead of again and again discussing this topic why not trying to implement what is required for the individual?
With regards, Morten.

basically you are right,

but when there are default wizzards supplied by every CB installation,
it should be allowed to discuss about, if the actual implementation is useful or not.
if everybody, who doesn't like a specific issue, changes it for his own installation it is of course ok,
but i would like to discuss how the "official" CB wizzards should be designed.

since it is a question of philosophy, it can't hurt if we get a few opinions, isn't it ?

takeshimiya

  • Guest
Re: Scripted wizards
« Reply #20 on: October 13, 2006, 08:36:08 pm »
but i would like to discuss how the "official" CB wizzards should be designed.

since it is a question of philosophy, it can't hurt if we get a few opinions, isn't it ?

Yep, it's the same I intended to say above:
Besides, no-one is stopping you to create a wizard with just one page, effectively simulating the dialog you 're suggesting ;).
Of course nothing stops no-one, but we have to discuss things first, right? If not, one could do a wizard in one way and another person in other way. And consistency would be lost.

This means, we know we can modify everything, since this is opensource, but we're talking about making better defaults for everyone.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Scripted wizards
« Reply #21 on: October 13, 2006, 08:49:09 pm »
since it is a question of philosophy, it can't hurt if we get a few opinions, isn't it ?
I didn't mean to offend here - I really wasn't sure if anybody is aware of the fact that indeed this is not a limitation of the scripted wizard plugin, but only the wizards itself as they are now. I surely didn't mean to suppress a discussion here (of course not) - but this will be endless if we don't come up with a sample implementation. And we had that discussion already...
So really: I only meant to clarify the facts and that's it. I fully respect and support a discussion of how things could be done better.
With regards, Morten.

Edit: And to add another opinion: For me at work (where round about 10 people using C::B) the Release/Debug philosophy has paid off as it is what we use most. In *my* humble option this is a good default. But I'm not pushing anything here.
« Last Edit: October 13, 2006, 08:52:32 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #22 on: October 13, 2006, 09:33:12 pm »
I didn't mean to offend here - I really wasn't sure if anybody is aware of the fact that indeed this is not a limitation of the scripted wizard plugin ...

surprisingly we now about that fact already

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #23 on: October 13, 2006, 09:38:34 pm »
...For me at work (where round about 10 people using C::B) the Release/Debug philosophy has paid off as it is what we use most. In *my* humble option this is a good default.

and how do you organize a simple project which consists e.g. of
1 - wxScintilla
2 - your custom dll with all your old goodies
3 - your wx app

with the Release/Debug approach ?

do you use different projects for for 1,2,3 and a workspace to hold them ?
do you have 3 times more effort to set all needed settings than if you would use one project with targets 1,2,3
which is easily expandable too ?


Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Scripted wizards
« Reply #24 on: October 13, 2006, 11:34:43 pm »
and how do you organize a simple project which consists e.g. of
1 - wxScintilla
2 - your custom dll with all your old goodies
3 - your wx app
In fact I have such a project. I organise these 3 points as projects. Each of these projects has a release and debug target and a virtual "all" that includes both. Maybe I don't get what you try to explain...?! :shock:
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: Scripted wizards
« Reply #25 on: October 14, 2006, 12:59:22 am »
just a shorty :

To be honest, one needs debug and release builds, for the simple reason that the final product should be a release build (== optimized), but then you can't debug, so you also need a debug build. Maybe think of it as debug/release configuration. So templates that setup these kind of configurations are good. And I am not just talking pc application, this also applies for embedded application, there (even more) you want optimized builds.

I think the example raised somewhere above of a project file with 3 targets:
 - component
 - test code
 - the app,
is not so nice in terms of I reusage of projects. I want people to reuse my component, and together with the source I provide them with a project file to build it (so they don't need to worry about defines, and other settings), but in that distribution my testcode and my app should be out. Well my component could be used in many apps (again think for example tinyxml) so why would "my"app by "the" app, far from it. From that point o view I provide debug build(configuration) (for people who like to debug it, in case they think there might be a problem on the inside), and the normal (preferred) usage would be the release configuration. And for dependent projects you can have a chain of debug's and a chain of release's. It's a nice "near"-standard. otherwise chaining for dependency will be less straight forward.

I don't say the other approach is not good, it is, otherwise we wouldn't have this exchange of ideas, but I feel it's not the best default. For sure in the pc world and definetely in the embedded world, debug/release configurations is what you need. Development and later on bugfixing requires the debug configuration, and the performance of the product requires the optimized (release) build (for example on a ti dsp, it's in speed 2 to 3 times faster in optimized build compared to debug build).

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Scripted wizards
« Reply #26 on: October 14, 2006, 08:46:38 am »
@killerbot
i second every word regarding the need for Debug- and Release- (and even other test-) builds.

but for the last time i want to say, that it is much less effort, if you organize them as projects
(Debug-Project, Release-Ansi-Project, Release-Optimized-Speed-Project, ...) instead as targets in each project.

building of the whole app is much more easy, and Creation of a new Build can simply be done by
copying the project file to  a new name and edit the project-wide settings
(with the Debug/Release/...-Targets approach you have to edit every single projectfile)

edit:
brgds, tiwag
« Last Edit: October 16, 2006, 08:16:17 am by tiwag »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: Scripted wizards
« Reply #27 on: October 14, 2006, 10:54:10 am »
Quote
but for the last time i want to say, that it is much less effort, if you organize them as projects
(Debug-Project, Release-Ansi-Project, Release-Optimized-Speed-Project, ...) instead as targets in each project.

little drawback : add a new file to the project --> modifying 3 projects, otherwise 1, and disritbuting severl project files instead of 1

Main thing : CB allows both, so we can have wizards for both kind of flavours, we just need to well document them, simple huh ... ;-)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Scripted wizards
« Reply #28 on: October 14, 2006, 12:20:37 pm »
I think tiwag is right in most of what he said, even though I am of course aware that it is in vain anyway.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Scripted wizards
« Reply #29 on: October 14, 2006, 02:08:05 pm »
I'd like to give an example where this does not apply:
At work we have several cross-platform applications (processes) that communicate with each other (via IPC) on different hardware platforms.
Thus all of these applications have it's own project, some of them share source files. Now each of these projects has several targets: Release and Debug; for Windows/Linux/QNX and another two for hardware-in-the-loop and software-in-the-loop simulations. This makes sense because the targets differ in the compiler (all compilers work on Windows but produce platform code), in the type of library to link against (platform, release, debug...) and in the defines applied for compilation.
As we have 2 major target platforms that have different hardware (one has less than the other), Thus we have 2 workspaces that include the projects (applications) for this specific platform. Virtual targets control the overall build process - thus, is it debug/release, do we want to build all applications in the workspace for one platform only (e.g. QNX) etc.
Now maybe I fail to understand but I believe that this is a good concept of project management for *our* case - at least it has proven to work very well. Maybe someone can tell me how to do this project- and not target-wise...?!

In the end: I think it is *very* good, that C::B supports both philisophies as I see that both have their pros and cons depending on what you are developing. For me the release/debug starting point is very good, because then I can just copy a target and adjust the parameters (defines, libs) for another platform but still have only one project per application running on all targets.

I have started to work on a concept for a "target wizard" though but I'd like to ask another question: Are you aware that currently it is possible to create an empty project using a wizard and then add only targets (that can be fully specified) to this project using another wizard? Would it be helpful to have a wizard that combines both to a single wizard?

Ps.: tiwag: In the end I don't like if someone calls others an i****t. I really try to think before I decide on how to setup projects and again: This setup have proven to work very well. We shouldn't come to a level here were we shout at each other.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ