Re: [cdt-dev] Build Configs in Navigator

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

I like where we're heading with this discussion. I've created a bug to
record to discuss further;

   https://bugs.eclipse.org/bugs/show_bug.cgi?id=322175

For now, comments below.

On Mon, Aug 9, 2010 at 2:48 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
> 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).

Yes, the build configs would be in a separate provider so could be
turned off that way.

>>
>> 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.

Possibly. BTW, I'm still very confused about having two of them. The
difference is very subtle and I need someone to explain it to me.

>> 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?)

Yes, these are things we could do once configs are objects in the UI.

>> 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.

I would worry about the decorator getting too noisy. You usually get
the Team repo info there too.

>> 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).

Adding Includes as a provider is probably a good idea as well. Our
content predates the common navigator. We should be leveraging it more
to provide this kind of information.

> +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.

That's one of my problems with the Includes folder. Does it really add
much value? Do people actually use it to browse /usr/include?

>>
>> 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?).

That had crossed my mind too years ago. Includes also predates linked
folders (or they came around the same time-ish). Supporting Open
Resource on your include path would be big plus.

Doug.