Bug 18639 – VisualD - First 5 minutes - Improve list of project wizards, propritise MSBuild projects

I have a colleague who just tried out D for the first time. He's a gamedev, so coming from VS, and expects a very high bar for quality. He offered me some feedback which I think it worth passing on. His first-5-minutes experience was not great, and he says he would have dismissed it and not continued investigating if not for my insistence. So, a few suggested changes: MSBuild seems to be working well. The project wizards need to promote it as the default if we think it's ready? New Project -> D -> [list is long] All the items in the list look reasonable to someone who doesn't know anything about VisualD, and it's not clear that they are distinct project types. I think most VS users will want VC++/D project, and it should probably be that there is a complete set of D MSBuild wizards, ie, windowed/console app, static lib, dll. The names need to be clearer in making a distinction between the MSBuild project, and the old VisualD custom project, and use language to promote MSBuild as the obvious choice?

Sorry, I didn't look at the bug list for a while. You might want to assign visuald reports directly to me so I get notified. I agree, the msbuild based projects look much better, but unfortunately, the custom projects still have some advantages, also found in your other reports: - add imports from project dependencies - demangling support - some special handling for error messages - integration with compiler generated JSON - better handling of link dependencies I'm on the fence whether we should make the msbuild version the recommended project type before solving these issues. I've changed the icon to look more like the C++ projects. Do you have suggestions for better wording? I guess templates for DLL and static libs should be added, too. More involved stuff would be nice, but needs external dependencies, e.g. vibe.d or UI libraries.

> - add imports from project dependencies Not sure what this means... 'add imports'? You mean dependent project's source-tree paths so clients can import modules from libs? How do you know a project's 'root' path? - demangling support Is this impossible? Can we bolt-in an output translator to the normal VS link stage? - some special handling for error messages What special handling? - integration with compiler generated JSON What integration is possible/missing? I don't know if I ever used this with the old projects...? - better handling of link dependencies What can't we do? Can we not just do all the same things that C++ does to make it all work the same way? I agree, we shouldn't switch over until the experience is tight, but the experience is close, and it doesn't look like a lot of work to get it there. There's a lot of missing wizards though for the various project types. > Do you have suggestions for better wording? Wording where?

(In reply to Manu from comment #2) > > - add imports from project dependencies > > Not sure what this means... 'add imports'? You mean dependent project's > source-tree paths so clients can import modules from libs? How do you know a > project's 'root' path? It adds the project path and the import path setting of the referenced project. > > - demangling support > > Is this impossible? Can we bolt-in an output translator to the normal VS > link stage? Not sure this is easy, as replacing the linker executable might have side effects, e.g. with respect to Tracker.exe (the tool that monitors build dependencies). > > > - some special handling for error messages > > What special handling? For example, it can interpret those horrible mixin filenames in error messages. There is also support to interpret stack traces (when running unittests from within Visual D). > > > - integration with compiler generated JSON > > What integration is possible/missing? I don't know if I ever used this with > the old projects...? That info was used by the first intellisense implementation and can still be used as a fallback. It is also used to populate the Object Browser. > > > - better handling of link dependencies > > What can't we do? Can we not just do all the same things that C++ does to > make it all work the same way? See https://issues.dlang.org/show_bug.cgi?id=18642 > > Do you have suggestions for better wording? > > Wording where? I was referring to this remark: > The names need to be clearer in making a distinction between the > MSBuild project, and the old VisualD custom project, and use > language to promote MSBuild as the obvious choice?

> I was referring to this remark > [...] Oh I see. Well, my immediate impression is that perhaps they shouldn't be split into 2 sub-sets like that; if the user just happens to click on the wrong one first, they'll find what they think they want and go with that, without understanding that the other set has the same things. So maybe combine them into one big list, but then for each project type, have a "Mixed C++/D" and "Just D" pair listed next to each other? It should be obvious at that point to the user that they need to make a choice, and they'll probably understand the choice they're making if the names are good. There's also help text that appears on the right. The "Mixed C++/D" ones can say the text "Produces a regular C++ .vcxproj file with additional support for compiling D files", and the other should say "Custom .visualdproj project type, with some improved support for [reasons...]. Also, [disadvantages...]", or something along those lines? I also feel like maybe there shouldn't be separate wizards for DMD, DMD/LDC, DMD/GDC, DMD/LDC/GDC; it would be better if that was an option presented in the wizard... like, in the C++ project wizards, you can select a whole bunch of extra 'advanced' options (like application type, 'empty', include a precompiled header, etc)

It seems to be standard to have all project types listed in the root node, and then filterd in sub nodes, so I was following that rule. I agree moving options to wizard settings would be best, but so far I have resisted trying to implement that... Maybe it would make sense to move the visualdproj/vcxproj decision into the wizard, too.

Oh, the wizard options dialog is not just part of the wizard framework? :) I've never tried to make one of those things... I can imagine it might be a hassle though. I feel kike that option might be best to stay outside the wizard actually... One, because it's actually a completely different project type; but also because then the user REALLY can't misunderstand that they are making an important choice when they create the project.

I've now reduced the number of project templates to 2 (one for each project type) followed by a wizard dialog. You can try a preliminary build here: https://ci.appveyor.com/project/rainers/visuald/build/1.0.173/job/b8h4eibmvy1eac0y/artifacts

Looks great! I'd change the text slightly: "This is based on a **custom** project type designed for the D programming language" <- I would add the word 'custom' to make it clear. And I'd append some detail about the current limitations to the D/C++ project rave. It might be nice to tweak the icons too, to make it more intuitive. I see what you did there with the D/C++ icon, but I feel like the 'D' in the top right gives the wrong message... I'd probably consider using that icon for the VisualD project, and put both pink C++ and red D on the other icon. Matching the icon style will make it clear they're both application project wizards. I also managed to crash the wizard. I created a VisualD project, and it worked fine, if I select DMD and LDC on the D/C++ wizard, it worked fine, but if I only choose DMD or LDC by themselves (with other options in default states), I get an exception.

(In reply to Manu from comment #8) > Looks great! > > I'd change the text slightly: > "This is based on a **custom** project type designed for the D programming > language" <- I would add the word 'custom' to make it clear. I actually removed "custom" from that line at some time ;-) But I have no strong preference. > And I'd append some detail about the current limitations to the D/C++ > project rave. I wanted to wait with that until it actually comes clear what these limitations will be in the next release. > I also managed to crash the wizard. I created a VisualD project, and it > worked fine, if I select DMD and LDC on the D/C++ wizard, it worked fine, > but if I only choose DMD or LDC by themselves (with other options in default > states), I get an exception. Yeah, the conditionals available during VS template generation are very brittle. I'm now trying another workaround, but also found a few other omissions with respect to project generation.

This should fix the exception and a couple of settings: https://ci.appveyor.com/project/rainers/visuald/build/1.0.174/job/596or7dhda3bpvim/artifacts

Situation is much better!