Community
Participate
Working Groups
When creating a new project, what I think I want to do is select the toolchain first, then the project type, then the template. Different toolchains support specific project types and specific templates. I’m coming at this from a cross-platform perspective, where the first thing you pick is what platforms you want to build your application for, and that drives what toolchains you’d use. So I’d like to see the toolchain and project type panes flipped, and the contents of the project types pane reflect the selected toolchains.
According internal implementation logic it is arguably more like [Project Type]->[Toolchain]->[Template] which I am guessing is not straightforward from user POV. So I think your suggestion certainly makes sense. Maybe we could drop [Project Type] altogether and just have: [Toolchain]->[Template] Selection of template would take care of the project type. The wizard would suggest "Empty Executable Project", "Empty Shared Library Project" etc. I don't anticipate that many templates for a toolchain so additional categorization of templates in folders is necessary. See also bug 234860 comment#37 and 39 which could be relevant.
My current thinking is that we need a new level for target platform, e.g., Windows, Linux, Android, vxWorks, ... Then if there are more than one toolchain for the selection platform, the user could select which one they want to use. I like the idea of just showing templates and skipping project types. But, yes, we would probably need folders as I'd like to promote more use of the template facilities. But then the top level folder could be project types. Hard to say. At any rate, this is something I want to get into CDT 8. Setting the defect accordingly.
(In reply to comment #2) > My current thinking is that we need a new level for target platform, e.g., > Windows, Linux, Android, vxWorks, ... I think so. We here would benefit from that as it is our main use case. I think we would need more support through other parts of CDT and project model as well, for example Build Location in project properties should support that.
(In reply to comment #2) > > My current thinking is that we need a new level for target platform, e.g., > > Windows, Linux, Android, vxWorks, ... Can you elaborate what exactly would be included in this new level? I am afraid I misinterpreted that. Is it to determine the binary kind of the artifact for debugging purposes?
(In reply to comment #4) > (In reply to comment #2) > > > My current thinking is that we need a new level for target platform, e.g., > > > Windows, Linux, Android, vxWorks, ... > Can you elaborate what exactly would be included in this new level? I am afraid > I misinterpreted that. Is it to determine the binary kind of the artifact for > debugging purposes? It could do that. But I'm coming from a UI perspective, to simplify the experience by filtering out the noise. When I create a new project, the first thing on my mind is where I'm going to run the resulting binary. Is it for my host machine, is it for a cross target like Android, or MinGW from Fedora, or what have you. Then I think about what kind of project. Is it a library, is it an executable, then I think of what kind of executable, e.g. is it a game using a certain game engine (i.e. template). Toolchain rarely enters the picture, but I assume once we get Visual C++ support, I'll want to pick between that and gcc for the Windows target. And to be honest, I want to pick my build system. Am I writing my own Makefile, do I want to use CDT's managed build, or CMake, or if I'm doing Qt, qmake. I want to say I'm building a static library using a Makefile. Maybe there's a template that does that for me. The big thing for me is hiding choices that aren't valid. Don't show me the Executable project for Android. It's not supported. And vxWorks has a totally different set of types. Don't show me things that only make sense in the desktop world. There's lots of things here. We need to work out what makes sense that is as flexible as possible while simple as possible. We need to document the workflows we want, which is probably the next step.
1. > Toolchain rarely enters the picture, In our integration, toolchain selection is a big part of it wince we support different version of in-house toolchains and gcc. 2. [Toolchain] and [Template] Just wanted to mention Bug 272103, which is on the CDT's inability to filter out templates.
(In reply to comment #6) > 1. > > Toolchain rarely enters the picture, > In our integration, toolchain selection is a big part of it wince we support > different version of in-house toolchains and gcc. Yes, of course. Rarely is relative. We have 600,000 CDT downloads from eclipse.org. In the big picture, few people need to select. But it is more than zero so we need to consider those use cases. My thinking is that we only show the selection of toolchain when there is a selection to make, e.g., if the icc toolchain is installed. > 2. [Toolchain] and [Template] > Just wanted to mention Bug 272103, which is on the CDT's inability to filter > out templates. I want to filter out toolchains as well.
(In reply to comment #7) > (In reply to comment #6) > > 2. [Toolchain] and [Template] > > Just wanted to mention Bug 272103, which is on the CDT's inability to filter > > out templates. > I want to filter out toolchains as well. Did you mean templates here?
(In reply to comment #5) I think there are several distinct flows and we should have different wizards or a big switch on the first page. This is brainstorming, please regard it as such: A) A new dummy CDT user (in many cases well experienced in C/C++). Asking question "How to write a C++ program in eclipse?". There should be some kind of new "Hello World" wizard. I see it as giving following: 1 page. Hello World executable/Hello World static lib (that would need to create 2 projects)/Hello World shared lib. 3 big pretty buttons showing. 2 (conditional) page. If there are several toolchains available, ask which one. If only one, do not ask and don't even show. This flow is actually similar to the current New Project wizard except that the current one confuses the hell out of newbie. B) Corporate user using in-house wizard. The wizard gives only a choice of approved toolchains+templates. Often just a choice of one. It shows a corporate logo icon. There should be an easy way for ISV to define a new wizard and its project-types/toolchains/templates set via an extension point. In our organization here we would require users to use this type of wizard. I think it does not matter that much how it is presented but it matters that user could create his regular project with minimal number of clicks. Just enter project name and hit Finish. If need another type of project, only one extra-click to select the type. C) Cross-platform project. My case is probably different than Doug's but I describe what we'd need here. 1. Choice of a toolchain. The toolchains are defined in our custom buildDefinitions to build on remote system (via Build command in Behavior tab). Each toolchain builds on different box (with different OS installed) remotely. We build with our own developed in-house build system. Effectively, the target platform is defined within the toolchain. Here I want a multi-selection of the toolchains so I get let's say 3 OS set in 3 different configurations after project creation. 2. Choice of empty project (prevailing case as it is used after checking out from CVS) or optionally template (skeleton project). D) Universal wizard like the current one which can do everything (except things it cannot) but does not really fit anybody's workflow. We already got that one.
I'm not sure it fits in the discussion but I think it would be great to have more specialized templates like "Simple SDL/OpenGL project", "OGRE project", etc. Templates could be separated in categories "General", "Multimedia", "Database", etc. The wizard could help setup the configuration like include paths, libraries... I think I saw something like that in Code::Blocks. Being a game programmer, I have more ideas in this field but I'm sure we could come up with others.
(In reply to comment #10) > I'm not sure it fits in the discussion but I think it would be great to have > more specialized templates like "Simple SDL/OpenGL project", "OGRE project", > etc. Templates could be separated in categories "General", "Multimedia", > "Database", etc. The wizard could help setup the configuration like include > paths, libraries... I think I saw something like that in Code::Blocks. Being a > game programmer, I have more ideas in this field but I'm sure we could come up > with others. Absolutely, that is what I've been hoping to see for a long time since Templates were introduced. We just haven't had anyone contribute any. We can consider categorization in this bug since it'll come into play as we reorganize the project types tree. Please raise another bug though to talk about the templates themselves. I think there are general questions that need to be answered, like how do we make sure the user can only select templates that he can use (e.g. if SDL or OGRE isn't installed).
(In reply to comment #1) > According internal implementation logic it is arguably more like [Project > Type]->[Toolchain]->[Template] which I am guessing is not straightforward from > user POV. So I think your suggestion certainly makes sense. Maybe we could drop > [Project Type] altogether and just have: > [Toolchain]->[Template] > Selection of template would take care of the project type. The wizard would > suggest "Empty Executable Project", "Empty Shared Library Project" etc. I don't > anticipate that many templates for a toolchain so additional categorization of > templates in folders is necessary. Note this doesn't work for ISVs who want to provide canned project templates which use a heterogeneous set of toolchains. As a concrete example, I'm generating a target-specific library project that has 3 configurations: - embedded_proc_lib - embedded_proc_exe - native_linux_exe The project contains configurations built using native and target gcc. From my POV the template engine stuff's integration with the MBS is hard to grock. I'm having to stare at the implementation to try to strong-arm it into just providing a simple canned project for users :(
(In reply to comment #12) > (In reply to comment #1) > > According internal implementation logic it is arguably more like [Project > > Type]->[Toolchain]->[Template] which I am guessing is not straightforward from > > user POV. So I think your suggestion certainly makes sense. Maybe we could drop > > [Project Type] altogether and just have: > > [Toolchain]->[Template] > > Selection of template would take care of the project type. The wizard would > > suggest "Empty Executable Project", "Empty Shared Library Project" etc. I don't > > anticipate that many templates for a toolchain so additional categorization of > > templates in folders is necessary. > > Note this doesn't work for ISVs who want to provide canned project templates > which use a heterogeneous set of toolchains. > > As a concrete example, I'm generating a target-specific library project that > has 3 configurations: > - embedded_proc_lib > - embedded_proc_exe > - native_linux_exe > > The project contains configurations built using native and target gcc. That's a good point. Having a template that targets multiple toolchains, like a multi-platform mobile app, makes a lot of sense. > From my POV the template engine stuff's integration with the MBS is hard to > grock. I'm having to stare at the implementation to try to strong-arm it into > just providing a simple canned project for users :( It's probably too integrated. Templates need to be elevated in the hierarchy of things.
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
