User forums > General (but related to Code::Blocks)

Scripted wizards

<< < (2/6) > >>

MortenMacFly:
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.

tiwag:

--- Quote from: mandrav 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...

--- End quote ---
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.

mandrav:

--- Quote from: Takeshi Miya on October 10, 2006, 01:28:19 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.

--- End quote ---

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 ;).

mandrav:

--- Quote from: tiwag on October 10, 2006, 01:44:16 pm ---
--- Quote from: mandrav 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...

--- End quote ---
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.

--- End quote ---

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.



--- Quote from: tiwag on October 10, 2006, 01:44:16 pm ---there is currently also the bug in the CB- workspace-build-system.

--- End quote ---

I heard a rumour that it has been revamped and is waiting to be committed ;)

takeshimiya:

--- Quote from: tiwag on October 10, 2006, 01:44:16 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.

--- End quote ---

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 ;)." :(


Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version