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.
Please create a public API to set and get Main project and delivers notifications when Main project changes. Suggested API: public Project OpenProjectList.getMainProject(); public void OpenProjectList.setMainProject(Project mainProject); ... SunStudio uses getMainProject() a couple a places. Our projects have Configurations and we have a configuration chooser (JComboBox) in the main toolbar that tracks the Main project's configuration. Our Welcome Page has a list of recent projects you can open by clicking on them and the option to open the project as the Main project. We use setMainProject for this purpose.
May be rejected. For configurations, there is already a separate RFE for an API to deal with active configs.
We need either setMainProjet or another option to open project so we can control whether the project should be opend as Main or not. We need getMainProject for other reasons (configurations. I don't quite understand the objection to making setMainProject and getMainProject public. I have asked for this several times before and so have others, and our requests have been rejected every time. And the result is we end up with ugly half-working hacks in our codes.
*** Issue 54637 has been marked as a duplicate of this issue. ***
Here is another use case: I plan to implement a "file quick-search" dialog (similar to the Go To Class dialog, but for all the files in a project instead of classes). Details at http://apisupport.netbeans.org/servlets/ReadMsg?list=dev&msgNo=416. The user should be able to choose if he wants to search in the current project or the main project. So I need to be able to get the main project.
The profiler needs to be able to determine the main project, IMO there is no reason to have API to get list of open projects and not having API to say which of them is main. Not being able to do this limits usability - e.g. the profiler offers at several places to select one of the projects, not knowing which of them is main limits the ability to make a wise default selection and/or mark the main project using Bold font. Note, that there is a hack that allows you to determine the main project - by creating a MainProjectSensitiveAction and invoke its actionPerformed method, you can find out what the main project is. It would be better to provide clean API to avoid people using dirty approaches.
To abadea: please take it to nbui because I think "current or main?" is a poor choice to offer. Should be e.g. "current or all open", i.e. not depend on the main project selection.
I would like to extend OpenProjects with getMainProject() and setMainProject() methods (see attached diff). I would like to ask for a review of this change
Created attachment 23944 [details] The patch.
"set none project as main" -> "set no project as main" Javadoc for the new methods should include an explanation of various circumstances where you would *not* want to call them - explain that IDE functionality is permitted to behave differently according to the current main project only as a last resort, i.e. that it is intended to be at a higher layer of the UI than most of the project system. Also I would recommend that potential clients of the new methods have their usages reviewed - some usages are noncontroversial but others may be missing a better approach. Also link to MainProjectSensitiveActions in Javadoc.
Created attachment 24222 [details] Updated patch.
I have attached an updated patch: -update to the current trunk -updated the javadoc descriptions to cover Jesse's comments If noone objects, I will commit this change tomorrow.
Implemented: Checking in projectui/src/org/netbeans/modules/project/ui/OpenProjectList.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectList.java,v <-- OpenProjectList.java new revision: 1.36; previous revision: 1.35 done Checking in projectui/src/org/netbeans/modules/project/ui/OpenProjectsTrampolineImpl.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectsTrampolineImpl.java,v <-- OpenProjectsTrampolineImpl.java new revision: 1.5; previous revision: 1.4 done Checking in projectui/test/unit/src/org/netbeans/modules/project/ui/OpenProjectListTest.java; /cvs/projects/projectui/test/unit/src/org/netbeans/modules/project/ui/OpenProjectListTest.java,v <-- OpenProjectListTest.java new revision: 1.6; previous revision: 1.5 done Checking in projectuiapi/apichanges.xml; /cvs/projects/projectuiapi/apichanges.xml,v <-- apichanges.xml new revision: 1.19; previous revision: 1.18 done Checking in projectuiapi/nbproject/project.properties; /cvs/projects/projectuiapi/nbproject/project.properties,v <-- project.properties new revision: 1.13; previous revision: 1.12 done Checking in projectuiapi/src/org/netbeans/api/project/ui/OpenProjects.java; /cvs/projects/projectuiapi/src/org/netbeans/api/project/ui/OpenProjects.java,v <-- OpenProjects.java new revision: 1.6; previous revision: 1.5 done Checking in projectuiapi/src/org/netbeans/modules/project/uiapi/OpenProjectsTrampoline.java; /cvs/projects/projectuiapi/src/org/netbeans/modules/project/uiapi/OpenProjectsTrampoline.java,v <-- OpenProjectsTrampoline.java new revision: 1.4; previous revision: 1.3 done
Great. Thanks for adding this api, but how do I get a notification when the main project changes. Is that possible?
what about the notifications when main project changes?
Indeed Jan you forgot to make a PROPERTY_MAIN_PROJECT. While we're at it, I just found a bug in OpenProjects. It uses OpenProjectsTrampolineImpl to refire events from OpenProjectList, which is a good start (e.g. it converts the property name "OpenProjects" to the API-mandated "openProjects" - why were these different to begin with??); but the property change event source will be a OpenProjectsTrampolineImpl, which is incorrect - should be the OpenProjects singleton instance, by the general JavaBeans contract that the event source is the same thing you attached your listener to.
As the behaviour is already in trunk I think we have a bug and not an enhancement. Preferably Jesse's comment should be fixed.
The second part of Jesse's comment seems unrelated to the rest of this issue, so I have filled issue #64397 for it. Re firing changes: I did not create PROPERTY_MAIN_PROJECT intentionaly, because I am not sure if this is something we should fire. Jesse, do you think we should fire such changes? Jarda, could you explain why is this issue a P2 defect? The API change passed through a api review and the second part of Jesse's comment is a separate bug (as above).
I don't see any reason not to fire it.
To avoid confusion, probably this issue should be CLOSED again, back in its original state, and a fresh API ENHANCEMENT (P2) filed for the property change.
Ok, I have created issue #64491 for firing the change. Closing this issue.