Community
Participate
Working Groups
This is to track a feature I'd like to do adding build configurations to the Project Navigator. Stay tuned for more info including the e-mail chain on this subject.
Latest in e-mail chain. On Mon, Aug 9, 2010 at 2:48 PM, Andrew Gvozdev <angvoz.dev@gmail.com> wrote: > On Mon, Aug 9, 2010 at 2:13 PM, <Ed.Swartz@nokia.com> 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.
(In reply to comment #1) > >> 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. One button is for actually building the configuration (the one with the hammer). I use it very often to either build a debug or release version. The other button is to switch completely to the building the configuration. I rarely use this one because it will trigger the indexer to completely rebuild the index (see bugzilla #183781 ). But it is useful when you want to see which code parts are active in debug or release mode. > >> 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. -1 for the label because of the team info (CVS repo and branch/tag name) > >> 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. OK, I am convinced and withdraw my +1. A filter option would be enough for me.
> -1 for the label because of the team info (CVS repo and branch/tag name) ... > 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 see the reasons for and against a label decorator and the build/config toolbar buttons. In our product, the workflow is different from the desktop environment, where you might have only Debug/Release configs. A user may have a set of SDKs for different phones contributing these configs, thus it may be common practice to switch the full editing and build context from phone A to phone B. So, the buttons and a label decorator are more convenient, while a subtree of configs inside the project tree may become unwieldly. Label decorators are usually configurable so they could be turned off in the default configuration. > 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? As for usefulness of files under Includes, I agree it's often a performance trap to expand a folder with lots of files in it, but this is often the easiest way to find a file whose name you don't exactly know. But yes, better Open Resource support would obviate this use case.
This is still on my wish list. Hopefully for Kepler.
