User forums > General (but related to Code::Blocks)
Scripted wizards
tiwag:
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:
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.
killerbot:
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 ;-)
mandrav:
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 ;)...
takeshimiya:
--- 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 ---
Yes that would be great. I can imagine a wxTree letting you choose the layout of the targets and projects.
--- Quote from: mandrav on October 10, 2006, 01:15:38 pm ---I, too, understand that editing a script is not as simple as editing an XML file but you get infinitely more power with scripts.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version