Community
Participate
Working Groups
We'll use this bug to manage my work on the CDT New Project Wizard. It's time to redo it's design. We've had a number of bugs raised in the past on usability of the wizard, and I've had my own series of complaints about it. I'll come up with a prototype for the wizard and check it in. It'll sit beside the existing one so we can compare and contrast, and turn it off if we need to scrap it.
The first thing I want to do is combine C and C++ projects into a single C/C++ Project and allow choice of language in the wizard.
Another questionable concept is project type as Andrew mentions here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=197802#c1. A project type just ends up being a filter used by option enablement, and not a whole lot else. Also, it is configuration specific. You can have multiple project types for a given project. One of the greatest advantages of the CDT build system is the ability to have build configurations with vastly different properties. When creating a new project things specific to configurations should be moved there.
Something that just crossed my mind, a new Build Configuration wizard. Looking at the New Project wizard, a lot of that is build configuration for the initial build configuration set.
Glad to hear you're working on this, Doug. Just so you know... Photran reuses the CDT New Project Wizard, adjusting the wizard title/description in the constructor and overriding #continueCreation, #getLanguageIDs, #getNatures, and #setCreated to (1) add the Fortran project nature to the C nature and (2) filter the dialog to show only Fortran project types and toolchains. It doesn't completely succeed at #2 -- e.g., the XL C/C++ project types still show up, and it's unintuitive that an Empty Makefile Project doesn't have any Fortran error parsers enabled -- but this isn't the fault of the project wizard. So, if it's possible for Photran to reuse the new New Project wizard as before, that would be ideal. And if it would be possible to replace the Empty Makefile Project type with our own, that would be an added bonus.
Our IDE for a custom C variant also has a wizard based on a CDT new project wizard. Can the language selection from comment#1 be made extensible? Also there may be a need for a more generic wizard name ("New C/C++ Project" will not work for Photran and other languages, like ours)
(In reply to comment #4) > Just so you know... Photran reuses the CDT New Project Wizard, adjusting the > wizard title/description in the constructor and overriding #continueCreation, > #getLanguageIDs, #getNatures, and #setCreated to (1) add the Fortran project > nature to the C nature and (2) filter the dialog to show only Fortran project > types and toolchains. Photran is definitely on my mind as I do this. Hopefully I can make it easier to manage, especially on the filters front. > It doesn't completely succeed at #2 -- e.g., the XL C/C++ project types still > show up, and it's unintuitive that an Empty Makefile Project doesn't have any > Fortran error parsers enabled -- but this isn't the fault of the project > wizard. I've already commented another bug about xlc and will try to clean that up for everyone. > So, if it's possible for Photran to reuse the new New Project wizard as before, > that would be ideal. And if it would be possible to replace the Empty Makefile > Project type with our own, that would be an added bonus. The empty project things are bizarre to begin with. There has to be a better way of dealing with them. We'll see what I can come up with.
(In reply to comment #5) > Our IDE for a custom C variant also has a wizard based on a CDT new project > wizard. > Can the language selection from comment#1 be made extensible? Also there may be > a need for a more generic wizard name ("New C/C++ Project" will not work for > Photran and other languages, like ours) We've struggled for years to come up with a name for CDT and family projects. Nothing is obvious. I think for now, having multiple entry points into the wizard still makes sense. At least per language (somewhat backing away from the C/C++ combined entry point idea), maybe per target, maybe per template.
Some suggestions, based on the changes I made to the wizard in Tilera's IDE: 1 - Consider adding an "intro" page that asks a few up-front questions regarding the most common project usages, and makes the corresponding changes on subsequent pages. Ideally, in the simplest projects, the user could just hit "Finish" without having to leave this initial page. Some examples: - project location (workspace or existing directory, and infer project name from project directory name) - project language (C/C++), since you're considering adding it - Makefile vs Managed (exe, shared lib, static lib) - platform (native vs Cross-GCC compilation) This can help a lot when a user wants to do something really simple, but does not recall exactly what that translates to in terms of project types, build tool chains, etc. (This still has value even if we clean up the project type selection page, as proposed by Bug 234860.) 2 - Make this "intro" page replaceable e.g. via an extension point, so integrators (such as myself :-) have the option of substituting a page that adds more questions (Example: for Tilera's IDE we also need to know whether the user is building for Tilera hardware, and if so which MDE installation they wish to use.) 3 - Consider making the wizard UI more programmatically drivable, so code like the intro page can make changes like setting the project name, selecting the project type, etc. I'll attach a screenshot of the intro page we use as an example. Regarding item 2, I've coded such an extension point, which I'd be happy to share it would be of use.
Created attachment 209469 [details] example of an "intro" page for the wizard
Nice UI! Can it also be used to import the sources (i.e. if the user selects directory that already contains the sources)? Would it be a stretch to add wizard from "Team->Share Project" into the wizard flow so the user could configure VCM when adding a project?
(In reply to comment #9) > Created attachment 209469 [details] > example of an "intro" page for the wizard This intro page idea is very nice! I would like to see the idea of projects that are outside of the workspace be extended to remote projects as well (via RSE etc.).
In my experience, users struggle with the concept of 'workspace'. It would be nice to hide that a bit. If they don't care where the project goes, we put it in the workspace. If they do care where it goes, chances are it's external, usually relative to some source control root. It might even be nice to have integrations with source control plug-ins to facilitate that.
The idea I'm starting to conclude on and will start prototyping is that we start with a basic new project wizard page that includes project name, location, and working set settings. After that, we elevate templates to be first class citizens, similar to visual studio. The user selects a template and that drives the remainder of the new project wizard. We can have generic "Empty" project templates that drive things like toolchain selection and configuration set up. I'll have to see how we'd organize the other templates, like the Hello World ones, maybe make them gcc specific. We'll definitely need to organize templates in categories and allow a search function to improve scalability. We'll learn more as the prototype proceeds. Thoughts?
I suggest that if we go the template route, we should make sure that: (a) the effect(s) of a template on the resulting project are clear and bounded, and should do just what's needed and no more -- one shouldn't have to use the template and then undo a number of things to get to the starting point you want. (This happens to me a lot in Visual Studio, where there are a zillion compiler/linker settings and it can be tedious undoing things the template has set for you. I find as a result that I tend to start with the minimal "Empty Project" template and work up from there -- it's just safer and more consistent when I know exactly what changes have been made to the project, beyond the most basic ones like kind of build product and tool(s) to use.) (b) it's easy to add new templates that can change settings in the wizard and/or the generated project -- for integrators, being able to quickly add a template for one or more specialized project types is important (c) it's easy to remove the predefined templates, so one can keep the template list down to a manageable set -- again, for integrators, it's just as important to be able to remove stuff the intended user(s) will likely not need to deal with It's clear that we need some way for the user to say "I need to do X" and quickly get to a known state with a project they can pour code into. Templates may be the answer, but we should take care that they don't become another long list of opaque options that the user needs to carefully choose from every time they create a new project. I was going to suggest dividing templates up into a "tree" of options (like first you choose a type of project, then content for it, etc. and each selection filters the ones that follow) but that's leading back to the current language/toolchain/build selection hierarchy again. It's a careful balancing act, no question.
(In reply to comment #0) > I'll come up with a prototype for the wizard and check it in. It'll sit beside > the existing one so we can compare and contrast, and turn it off if we need to > scrap it. Would it be a good idea to work on this in a separate feature branch? If we need to scrap it then it just won't be merged in master.
(In reply to comment #15) > (In reply to comment #0) > > I'll come up with a prototype for the wizard and check it in. It'll sit beside > > the existing one so we can compare and contrast, and turn it off if we need to > > scrap it. > > Would it be a good idea to work on this in a separate feature branch? If we > need to scrap it then it just won't be merged in master. Nah, that's a pain. Doing it in master forces me to keep things working with both wizards in place. If we decide to scrap it, we just remove the extension and it disappears for the user. BTW, in case you haven't seen it, the beginnings of it are there now (New->C/C++ Project (new)). I'm really liking how the workflow is working with templates elevated to first class citizens. It so much easier to understand.
(In reply to comment #15) > (In reply to comment #0) > > I'll come up with a prototype for the wizard and check it in. It'll sit beside > > the existing one so we can compare and contrast, and turn it off if we need to > > scrap it. > Would it be a good idea to work on this in a separate feature branch? If we need > to scrap it then it just won't be merged in master. I agree with Marc on that. I think it is better development practice to do side development on a branch and merge to master when it is ready. That was a pain to keep up with the HEAD in CVS but with git, you can easily rebase anytime you like.
(In reply to comment #17) > (In reply to comment #15) > > (In reply to comment #0) > > > I'll come up with a prototype for the wizard and check it in. It'll sit beside > > > the existing one so we can compare and contrast, and turn it off if we need to > > > scrap it. > > Would it be a good idea to work on this in a separate feature branch? If we need > > to scrap it then it just won't be merged in master. > I agree with Marc on that. I think it is better development practice to do side > development on a branch and merge to master when it is ready. That was a pain > to keep up with the HEAD in CVS but with git, you can easily rebase anytime you > like. Call me old school then :). This feature isn't big enough, nor intrusive enough to warrant that. And it shouldn't take too long to be ready for people to try.
(In reply to comment #13) > We can have generic "Empty" project templates that drive things like toolchain > selection and configuration set up. I'll have to see how we'd organize the > other templates, like the Hello World ones, maybe make them gcc specific. We'll > definitely need to organize templates in categories and allow a search function > to improve scalability. We'll learn more as the prototype proceeds. > > Thoughts? I don't know, that sounds like a lot of templates. I think selecting a set of toolchains (maybe call it Target platform?) first would bring that number down. Then the user could select one of the templates compatible with this set. That way, the same template can be reused for many toolchains, like is it currently done with the core.templateAssociations extension point. I like the idea of having a search function in case of many templates. But I would not want a beginner to have to search for "Hello world" because it's buried in a long list. Chances are that the beginner doesn't know what to look for in the first place.
(In reply to comment #19) > I don't know, that sounds like a lot of templates. I think selecting a set of > toolchains (maybe call it Target platform?) first would bring that number down. > Then the user could select one of the templates compatible with this set. That > way, the same template can be reused for many toolchains, like is it currently > done with the core.templateAssociations extension point. The templates will be organized in a tree with uber flexibility at defining the hierarchy. Target platforms would be an obvious choice for a category but I don't want to restrict that. That should make the list of templates managable (BTW, we really only have a small handful out of the box). > I like the idea of having a search function in case of many templates. But I > would not want a beginner to have to search for "Hello world" because it's > buried in a long list. Chances are that the beginner doesn't know what to look > for in the first place. That exactly it. A beginner doesn't know what a toolchain is either. Let's play with the hierarchy and make sure things like the Hello World templates are easy to find.
(In reply to comment #16) > > Would it be a good idea to work on this in a separate feature branch? If we > > need to scrap it then it just won't be merged in master. > > Nah, that's a pain. Doing it in master forces me to keep things working with > both wizards in place. If we decide to scrap it, we just remove the extension > and it disappears for the user.es elevated to first class citizens. It so much easier to understand. Please consider branching. If the new wizard is not adopted, it will leave superfluous changes and unused code. The CDT code base is confusing enough as it is. Also, if it's in a separate branch, it makes the feature much easier to code review since we can diff between the two branches. (In reply to comment #20) > That exactly it. A beginner doesn't know what a toolchain is either. Good point! (In reply to comment #20) > The templates will be organized in a tree with uber flexibility at defining the > hierarchy. Target platforms would be an obvious choice for a category but I > don't want to restrict that. That should make the list of templates managable I see you've added the parentCategory element in the Template definition and that a template can have multiple parentCategory elements. Say for the Hello World template, would it have a parentCategory of MinGW, another one for Cygwin, etc? Does that mean an externally contributed toolchain can't be associated with the Hello world template? Maybe toolchains shouldn't be categories because of this. I'm thinking, maybe the core.templateAssociations extension point could still be supported by appending toolchain name to the template name, example: "Hello World using MinGW GCC" "Hello World using Cygwin GCC" "Hello World using Microsoft Visual C++" ... > (BTW, we really only have a small handful out of the box). It would be great to have many more! Perhaps in a optional plugin/feature. I'd be willing to work on that (bug 197802 comment 10).
I'm really liking how this is turning out with the focus being on the templates. It greatly enhances the usability of the CDT new project wizard. And doing a quick survey, all major IDE's do it this way. Unless I get a veto, this is going through. For the Hello World template, there are a couple of ways to go. The choice of toolchain will likely be one of the template pages (and make it reusable for other templates). I wouldn't create separate templates for each. Again, I'm anticipating the user doesn't really know what toolchain they're using. If they only have one toolchain installed, there would be no need to present the choice, which would be confusing anyway. I'll also create an Empty Project wizard that will allow for selecting project types and toolchains, just like we have now. Stay tuned. I'll be working more on this once M5 is out.
*** cdt git genie on behalf of Doug Schaefer *** Bug 368552 - Hooked up template wizard pages. [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=7585db1990bcc82c440a5dbd65b5d8e76cd5f835
*** cdt git genie on behalf of Doug Schaefer *** Bug 368552 - Hooked up template wizard pages. [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=7585db1990bcc82c440a5dbd65b5d8e76cd5f835 *** cdt git genie on behalf of Doug Schaefer *** Bug 368552 - Hooked up template wizard pages. [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=7585db1990bcc82c440a5dbd65b5d8e76cd5f835
*** cdt git genie on behalf of Doug Schaefer *** Bug 368552 - Hook up finish button. [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=453f71f4c4f4fdc8652d308c30a6a538c471d6f0
(In reply to comment #22) > If they > only have one toolchain installed, there would be no need to present the > choice, which would be confusing anyway. There would be no need to present the choice but I think the automatically selected toolchain should still be mentioned somewhere, maybe in a less intrusive way then a page. It's possible that the only one toolchain detected is wrong and that the user actually wants a second toolchain that wasn't detected properly. > Stay tuned. I'll be working more on this once M5 is out. Is it safe to assume this won't make it into Juno? Just want to know whether I should look into committing fixes for bug 353786 / bug 353790 or not.
(In reply to comment #26) > (In reply to comment #22) > > If they > > only have one toolchain installed, there would be no need to present the > > choice, which would be confusing anyway. > > There would be no need to present the choice but I think the automatically > selected toolchain should still be mentioned somewhere, maybe in a less > intrusive way then a page. It's possible that the only one toolchain detected > is wrong and that the user actually wants a second toolchain that wasn't > detected properly. > > > Stay tuned. I'll be working more on this once M5 is out. > > Is it safe to assume this won't make it into Juno? Just want to know whether I > should look into committing fixes for bug 353786 / bug 353790 or not. Yeah, I finally got back into thinking about this today. The transition to QNX was more complicated than I planned. This feature is certainly at risk of making it into Juno given how little time I have left to work out the issues. If you have fixes the the existing wizards, I'd put them in. I'll make a decision by tomorrow what I want to do here. Leaning towards deferring at the moment since this is a pretty major user impacting change that needs more time to mature.
Yes, I am deferring. There just isn't enough time and I want to focus on fixing various bugs from here on in with Juno.
It would be nice to have general selection for globaly preferred toolchain, thus to extend individual preferred toolchain.
What about to have posibility to have capability to include configurations for frameworks as extension. E.g. something like: generic libraries, UI, shared configuration settings, unit testing, reporting frameworks. And depending on installed features to be able to combine them. Also could be nice to have grouping by keyword or feature.
(In reply to comment #30) > What about to have posibility to have capability to include configurations for > frameworks as extension. E.g. something like: generic libraries, UI, shared > configuration settings, unit testing, reporting frameworks. And depending on > installed features to be able to combine them. Also could be nice to have > grouping by keyword or feature. By switching things around to be template centric, as long as templates are provided for these things, it should be possible.
Created attachment 239707 [details] Dialogs with discrepancies associated with discovery configurations at project, system, and new project access points.
Would it be possible to reconcile the project vs system vs new project configuration pages? Would that be less confusing? I have added an attachment showing the discrepancies I find confusing. Here is a specific proposal to address the dialog boxes and functionality: Current sources of confusion: * The discovery option dialogs do not match (see attachment). They are called "Discovery" in the top left dialog, "Discovery Options" in the top right dialog, and "Providers" in the bottom dialog. In the top left there are no check boxes (although there are checkboxes in its sibling -- Error Parsers.) * It is not possible, even using plugin_customization.ini, to set the default discovery options - even if you do it in the top right dialog, the Makefile project still uses "User Settings" and "Managed Build Settings" (does the latter even make sense for a makefile project)? If you try to select "Automate discovery of paths and symbols", you get the confusing (i.e., bug 142619) message "This discovery method is deprecated, use 'Preprocessor Include Paths' instead", and the "GCC per file scanned" setting seems to be ignored. The suggestion is to simplify this workflow in one of two ways. Either: 1. Drop the two tabs "Error Parsers" and "Discovery Options" from the New Project (top-right) dialog and use the settings from the System (top-left) dialog; and add checkboxes to the "Discovery" tab in the System (top-left) (like in its sibling "Error Parsers" and the Project (bottom) dialog; then use those settings for new projects. or 2. Copy the tab from the Project (bottom) dialog onto what is currently "Discovery Options" in the New Project (top-right) dialog; and rename all three tabs to the same thing. "Discovery" maybe? This way, at least the project settings and the system-wide settings have the same interface, and the user doesn't have to change the settings every time they create a new project. Thanks for considering it. Please let me know if you have further questions.
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.
