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 58461 - public api to get and set Main project
Summary: public api to get and set Main project
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jan Lahoda
: 54637 (view as bug list)
Depends on: 64491
Blocks: 62915
  Show dependency tree
Reported: 2005-04-30 01:25 UTC by Thomas Preisler
Modified: 2006-07-11 19:39 UTC (History)
4 users (show)

See Also:
Exception Reporter:

The patch. (9.13 KB, patch)
2005-08-16 14:56 UTC, Jan Lahoda
Details | Diff
Updated patch. (9.90 KB, patch)
2005-08-25 10:02 UTC, Jan Lahoda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Preisler 2005-04-30 01:25:31 UTC
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.
Comment 1 Jesse Glick 2005-04-30 06:04:40 UTC
May be rejected. For configurations, there is already a separate RFE for an API
to deal with active configs.
Comment 2 Thomas Preisler 2005-04-30 18:31:24 UTC
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.
Comment 3 Jesse Glick 2005-05-10 17:14:43 UTC
*** Issue 54637 has been marked as a duplicate of this issue. ***
Comment 4 Andrei Badea 2005-07-29 07:13:14 UTC
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 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.
Comment 5 iformanek 2005-07-29 07:44:31 UTC
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.
Comment 6 Jesse Glick 2005-07-29 20:20:29 UTC
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.
Comment 7 Jan Lahoda 2005-08-16 14:55:05 UTC
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
Comment 8 Jan Lahoda 2005-08-16 14:56:27 UTC
Created attachment 23944 [details]
The patch.
Comment 9 Jesse Glick 2005-08-16 16:42:36 UTC
"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.
Comment 10 Jan Lahoda 2005-08-25 10:02:48 UTC
Created attachment 24222 [details]
Updated patch.
Comment 11 Jan Lahoda 2005-08-25 10:04:24 UTC
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.
Comment 12 Jan Lahoda 2005-08-26 10:50:23 UTC
Checking in projectui/src/org/netbeans/modules/project/ui/;
new revision: 1.36; previous revision: 1.35
Checking in
new revision: 1.5; previous revision: 1.4
Checking in
new revision: 1.6; previous revision: 1.5
Checking in projectuiapi/apichanges.xml;
/cvs/projects/projectuiapi/apichanges.xml,v  <--  apichanges.xml
new revision: 1.19; previous revision: 1.18
Checking in projectuiapi/nbproject/;
/cvs/projects/projectuiapi/nbproject/,v  <--
new revision: 1.13; previous revision: 1.12
Checking in projectuiapi/src/org/netbeans/api/project/ui/;
new revision: 1.6; previous revision: 1.5
Checking in
new revision: 1.4; previous revision: 1.3
Comment 13 Thomas Preisler 2005-08-26 18:15:58 UTC
Great. Thanks for adding this api, but how do I get a notification when the main
project changes. Is that possible?
Comment 14 Thomas Preisler 2005-09-15 00:59:43 UTC
what about the notifications when main project changes?
Comment 15 Jesse Glick 2005-09-15 02:09:47 UTC
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.
Comment 16 Jaroslav Tulach 2005-09-15 07:24:18 UTC
As the behaviour is already in trunk I think we have a bug and not an 
enhancement. Preferably Jesse's comment should be fixed. 
Comment 17 Jan Lahoda 2005-09-15 07:48:16 UTC
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).
Comment 18 Jesse Glick 2005-09-15 19:18:20 UTC
I don't see any reason not to fire it.
Comment 19 Jesse Glick 2005-09-15 19:19:28 UTC
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.
Comment 20 Jan Lahoda 2005-09-15 19:24:00 UTC
Ok, I have created issue #64491 for firing the change. Closing this issue.