This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 210304 - Show active config name in context menu items for project actions
Summary: Show active config name in context menu items for project actions
Status: RESOLVED WONTFIX
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Tomas Stupka
URL:
Keywords: UI
: 213194 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-28 16:33 UTC by tbrunhoff
Modified: 2016-07-07 08:39 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tbrunhoff 2012-03-28 16:33:50 UTC
More recently, with the move away from "Main Project" and other changes, it appears that NB is more confused about configurations.

For example, I typically have between 7 and 10 projects open, comprised of 6 or 7 libraries and one or more applications. Every project has four common configurations:
 - DebugLinux
 - DebugLinux64
 - Linux
 - Linux64

But their declarations within the XML may be in different orders. So what appears to happen is that if I open a set of projects on a clean snv checkout, they will all have different configurations (seen with right-click-->set configuration) corresponding to the first declared configuration.

This leads to unexpected problems when I right click on a project and select build, and I get a non-debug compilation, even though the main project is selected as debug.

And there appears to be no way to change them all to match. I would think that the configuration pulldown on the tool bar would change them all to match.

I can work around this, but it seems a bit disorganized right now.
Comment 1 Vladimir Voskresensky 2012-03-28 17:11:40 UTC
Todd. bug title also mentions code model. Can you clarify, please?
Comment 2 Vladimir Voskresensky 2012-03-28 18:13:51 UTC
Todd can you clarify your confusion with configurations as well.
I.e. I play with 2 Pi sample projects (they have several configs by default):
- when no Main project
- when one project is marked as Main
=> I see different behavior of combobox with configurations, but it's the same as before.
Comment 3 tbrunhoff 2012-03-28 18:59:39 UTC
> bug title also mentions code model. Can you clarify, please?

Code model is more related to another bug I just files: Bug 210312. Sorry. Please ignore that statement.

> can you clarify your confusion with configurations as well.

Ok, perhaps this is simpler than what I stated above. If I have two projects named "App" and "Lib". At link time, App requires Lib to be up to date. So my Makefile for App also builds Lib. And if I right click on App and select build, it will do the right thing.

However, let's say that both projects have two configurations: Linux32 and Linux64. In a command line environment, I might build App (which builds Lib) or I might just build Lib, but I would control the build with command line args like:
    make PLATFORM=Linux32
And its my fault if I build App or Lib them with different argument.

Within NB, if I have App selected as Main Project and the configuration pulldown in the toolbar set to Linux32, I expect building App to do the right thing... and it does, because my makefiles are set up to pass the PLATFORM argument down to the required subprojects.

However... in NB the *default* configuration on a new tree appears to be the first configuration in the xml file. This is how I ended up with the toolbar configuration pulldown set to Linux32 and the Lib configuration set to Linux64. So when I right click on Lib and select build, it builds *my view* of the wrong thing.

Possibly the only thing missing is visual feedback. When I right-click on Lib, the context menu should say "build Linux64", not just "build". Otherwise I have to go browse the "set configuration" menu every time just to figure out what will be built.
Comment 4 Vladimir Voskresensky 2012-03-28 21:02:31 UTC
(In reply to comment #3)
> > bug title also mentions code model. Can you clarify, please?
> 
> Code model is more related to another bug I just files: Bug 210312. Sorry.
> Please ignore that statement.
> 
> > can you clarify your confusion with configurations as well.
> 
> Ok, perhaps this is simpler than what I stated above. If I have two projects
> named "App" and "Lib". At link time, App requires Lib to be up to date. So my
> Makefile for App also builds Lib. And if I right click on App and select build,
> it will do the right thing.
> 
> However, let's say that both projects have two configurations: Linux32 and
> Linux64. In a command line environment, I might build App (which builds Lib) or
> I might just build Lib, but I would control the build with command line args
> like:
>     make PLATFORM=Linux32
> And its my fault if I build App or Lib them with different argument.
> 
> Within NB, if I have App selected as Main Project and the configuration
> pulldown in the toolbar set to Linux32, I expect building App to do the right
> thing... and it does, because my makefiles are set up to pass the PLATFORM
> argument down to the required subprojects.
> 
> However... in NB the *default* configuration on a new tree appears to be the
> first configuration in the xml file. This is how I ended up with the toolbar
> configuration pulldown set to Linux32 and the Lib configuration set to Linux64.
> So when I right click on Lib and select build, it builds *my view* of the wrong
> thing.
> 
> Possibly the only thing missing is visual feedback. When I right-click on Lib,
> the context menu should say "build Linux64", not just "build". Otherwise I have
> to go browse the "set configuration" menu every time just to figure out what
> will be built.
Thank you for details explanation. May be it was the reason why Set As Main is trying to be removed from NB.
As I checked, if you do not have Main project (i.e. use Unset as Main or Run->Set As Main->None) => then each time you change node in Projects tab tree => combobox reflects configuration of "current" project.
But when at least one project is set as Main => toolbar always shows configuration of main project and changing in combobox affects exactly Main project.

My other question was: how it is different from, let's say 7.1
Comment 5 Jesse Glick 2012-03-28 21:23:01 UTC
(In reply to comment #4)
> if you do not have Main project [...]
> then each time you change node in Projects tab tree
> => combobox reflects configuration of "current" project.
> But when at least one project is set as Main => toolbar always shows
> configuration of main project and changing in combobox affects exactly Main
> project.

Correct. Also you can directly set the configuration of a particular project, main or not, from the submenu in its context menu.

To comment #3, the generic Build/Run/etc. context menu items in the IDE do not display the name of the configuration in effect since for most project types this is rarely crucial. It may be appropriate for CND project types to use customized context menu items which display the configuration name, or some relevant aspect of it (such as architecture).

Or perhaps the generic context menu items should always show the configuration name when it is not the default; would need to be reviewed by UI, and would also need an API change to ProjectConfiguration or ProjectConfigurationProvider to indicate default vs. nondefault configs (or otherwise decorate menu items).
Comment 6 Jesse Glick 2012-03-28 21:24:40 UTC
BTW there is no regression here in 7.2 that I know of. While the UI to set a main project has been partly suppressed, once set it should behave like it did in 7.1. There were no changes in the UI of configurations that I know of, at least in the generic project system. So I am not really sure why this is marked P2.
Comment 7 Vladimir Voskresensky 2012-03-28 21:33:29 UTC
(In reply to comment #6)
> BTW there is no regression here in 7.2 that I know of. While the UI to set a
> main project has been partly suppressed, once set it should behave like it did
> in 7.1. There were no changes in the UI of configurations that I know of, at
> least in the generic project system. So I am not really sure why this is marked
> P2.
I agree with Jesse, that's why I'm trying to understand where is the confusion which is "recent" (i.e. comparing to 7.1)
Comment 8 tbrunhoff 2012-03-28 21:35:44 UTC
> My other question was: how it is different from, let's say 7.1

Now that I think about it perhaps it was not different than 7.1. But the shift in Main project has made me think about this.  Also, the other bug filed today, Bug 210312, suggested (to me) that different configurations might influence the parser in odd ways. Does it? This other bug shows a definite regression.

So without considering how the selection of project configuration affects parsing, Jesse is correct: no regression WRT 7.1.
Comment 9 Vladimir Voskresensky 2012-03-29 08:26:57 UTC
Todd, I'm changing this to ENH and reassign to project sytem in the following way:
- user wants to see name of configuration in Clean, Build and other actions in project's context menu
Comment 10 Jesse Glick 2012-03-29 17:06:17 UTC
OK, UI comments requested. After some experimentation, I settled on this proposed behavior:

For regular project command actions (Build, Run, Test, and similar) displayed in the context menu of a single project selection, when there is a main project set but it is not the selected project, and the two projects have differently-named active configs - i.e. when the global combo box might be showing a different config than what you are about to actually run! - then display the config name at the end of the context menu item label, e.g.

  Run Linux64

or

  Run <default config>

The labels using "ACTION CONFIG" format do not look good for e.g. "Debug" as a config name ("Debug Debug"?), but I am not sure what punctuation would most clearly convey the config name. I experimented with "ACTION [CONFIG]" but this looks bad for <default config>. Maybe "ACTION @CONFIG"? "ACTION ⊢ CONFIG"? (Would rather not use an English word or phrase both because it might be too long for a popup, and because it would not translate well in different combinations with action name.) Seems to work with @ so long as the suffix is in italicized control font so it is clearly set off from the rest of the label and not too prominent.
Comment 11 tbrunhoff 2012-03-29 17:19:25 UTC
> The labels using "ACTION CONFIG" format do not look good for e.g. "Debug"
> as a config name ("Debug Debug"?)

That would be a bad choice of names by the user, in the same way that selecting "Run" as the name of a config results in "run run". If you are really inclined to fix this perhaps using a different font, e.g. bold/italic, for the configuration name would clarify.
Comment 12 Jesse Glick 2012-03-29 17:24:49 UTC
Just committing what I have, which provides a basis for testing; if the UI needs to be tweaked, or the change reverted altogether, that is easy enough. core-main #b4f0c6004578
Comment 13 Jesse Glick 2012-03-29 17:30:44 UTC
(In reply to comment #11)
>> "Debug Debug"?
> 
> That would be a bad choice of names by the user

This particular config name was picked by default in the C++ templates (the other is "Release").

> using a different font, e.g. bold/italic, for the configuration name

Yes, as mentioned offhand in comment #10 the current impl puts the config name (and '@') in italics and also uses the "controlShadow" font (same as Swing uses to display e.g. accelerators).

From experimenting on both Make-based C/C++ and Ant-based Java SE projects it looks OK in a variety of contexts. Note that it does not currently work for Profile (on Java projects), though I expect the fix of bug #203519 to resolve that.
Comment 14 Jesse Glick 2012-05-30 20:41:44 UTC
*** Bug 213194 has been marked as a duplicate of this bug. ***
Comment 15 Milos Kleint 2012-09-25 08:35:26 UTC
reopening, caused issue 214918 and issue 214909, I've reverted the patch.

from 214918:
"We can show the active configuration in Set Configuration > menu item if
really, really necessary.
Eg. Set Configuration @ Debug > which will be shown all the time, not only when
there is another project set as main and the current config differs from the
main project's one."
Comment 16 Martin Balin 2016-07-07 08:39:09 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss