On Mon, Aug 9, 2010 at 2:13 PM,
<Ed.Swartz@xxxxxxxxx> wrote:
Hi,
I was out, so didn't get a chance to reply to this in a timely manner, but:
Axel:
> +1 for adding the Build Configurations to the Project Navigator.
Agreed, as long as the user can turn this node off as needed (via the arrow menu > Customize View).
Doug:
> One advantage is that we could get rid of the confusing dual toolbar buttons we have now and replace them with menu items on the Configurations.
Removing the toolbar buttons might make building a configuration difficult for some users. If you got a big project and in the middle of the source tree in Project Explorer it would be counterproductive to have to navigate back to project root just to build your configuration. The toolbar buttons are handy in this case.
I have some questions about the functioning of the feature as you see it. Would one config have a checkmark or some bold font to indicate the current configuration? How do you add/remove/edit configurations in the tree? (Does it bring up the config manager dialog?)
One way to alleviate a major bit of the confusion about configurations is to use a label decorator for the CDT C project node, showing the active configuration's name in brackets (e.g. "myProject [Debug]"). Having to hover over a button or dig into a menu or property page to find out what config you're building for is lot more confusing than the buttons themselves, IMO.
Axel:
> +1 for removing the Includes
> I use it only to check the scanner discovery. But this can be
> also done in the Project Properties (Paths and Symbols).
Well, -1 for this from me, if someone's proposing removing it completely. It would be better to allow filtering it (via arrow > Customize View). Currently there's no entry for the CDT elements other than Binaries and Object Files in this list (just a way to hide non-CDT elements).
+1 for keeping that with ability to filter. Although I find "Includes" somewhat confusing - in respect that they are under project root folder but show include paths defined on the level of individual folders too.
Another important use case for Includes is easily discovering and opening the header files in those paths. Ctrl-Shift-R (Open Resource) doesn't work for the folders outside the workspace, unless you make a linked folder pointing to your SDK (yuck).
I was thinking that we might introduce error markers decoration when build error happens to point to an include file. One way would be to create automatically linked folders/files pointing there for example when include paths are being defined (yuck?).
Andrew
And other than adding a fake #include for some file you want and hitting F3 on it (also yuck, requiring you know the exact spelling of the file), there's no convenient way to do this.
-- Ed
