Bug 139019 - The concept of Main Project is confusing to PHP users
The concept of Main Project is confusing to PHP users
Status: VERIFIED FIXED
Product: projects
Classification: Unclassified
Component: Generic Projects UI
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Milan Kubec
issues@projects
http://wiki.netbeans.org/MainProjectC...
: PLAN, UI, USABILITY
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-04 11:21 UTC by Petr Jiricka
Modified: 2009-10-29 00:38 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2008-07-04 11:21:25 UTC
During the PHP usability study, several participants were confused by the concept of the "main project". In the context
of PHP development, this concept does not really make sense, as there is no project dependency hierarchy, and all
projects are "top level". When editing a file in the editor, users expect that this file's project will be run after
hitting the Run button.
For more information, see also http://wiki.netbeans.org/PhpUsabilityStudyNotes

The solution should be to either eliminate or deemphasize the concept of Main Project, so the prominent menu
items/toolbar buttons/shortcuts are bound to the active project. See also an e-mail that Jesse G posted on a related
subject:
http://jupiter.czech.sun.com/mailarchives/nb-usability-log/3994.html
(sorry, Sun-internal link only).
Comment 1 David Konecny 2008-07-10 07:42:57 UTC
I agree that for couple of new project types the concept of Main Project does not make much sense, PHP, Grails, or Rails
being examples. If I remember well main project concept was designed for scenario when your application is composed from
several projects and despite which project is active user always want to compile/run/debug "main" one. Example could be
Java Application project depending on several Java Library projects or Ear project consisting of Web and EJB projects.

One idea how this could work without main project concept is to simply ask for a project. For example when shortcut for
execute/debug is triggered and Java Library project is active then dialog asking for a main class is shown (if not
already set) and this dialog could contain also combo box with all opened projects in IDE letting user choose "main"
one. Selected project would be also configurable in Run tab in Project Properties. Compile action can always work just
on active project.

Are you aware of any other scenario where main project is useful or used now? Run to Cursor/into Method is variation of
Debug scenario. Set Main Project Configuration can be changed to be active project sensitive.
Comment 2 jrojcek 2008-07-10 12:33:51 UTC
I remember many discussions about the main project concept and I'm still skeptical to any kind of automatic guessing about what the user wants to run. I tried the 
latest Eclipse release which tries to do just that and after a while I got pretty lost in what it was actually running. Maybe it just tried to be too smart.

I would suggest to stick with the main project concept as it is, just try to provide some better clues that would explain the concept and let those who don't need it, deal 
with it as smoothly as possible. Therefor I like David's idea about asking the user what to do. I can imagine it would work like this:

- The IDE sets the main project automatically as it does now (upon creating a new project or opening a project)
- If the user views a file in the editor that belongs to a non-main project and hits the Run Main Project action, the IDE would show up a dialog like this:

---
Run Main Project - title
---

File "Foo.java" (viewed in the editor) does not belong to main project "BarProject"

Select which project to run:
  (o) Run "FooProject" Project
  ( ) Run "BarProject" and set it as Main Project

[[ Run ]] [ Cancel ]
---

The default choice would be the project containing the viewed filed. Ideally the dialog would show up only if the viewed file isn't in a project that's a main project 
dependency. In other words only if the viewed file is completely unrelated to the main project.

Such solution would let PHP developers quickly switch context they're working on (just hit Enter in the dialog), without having to go and set the main project manually. 
It would be deterministic and work well for Java developers who work on applications composed of multiple projects.

Comment 3 Milan Kubec 2008-07-10 16:10:27 UTC
I don't really like more dialogs in the work flow, especially when running the project. 

We already have an action 'Run Project' that runs currently active project, it means e.g. project which contains file currently edited in editor or selected in 
Explorer, so why not move this action more towards to user. Currently the action is not assigned to any shortcut, I tried to assign it to F10 and it works as 
expected. Also other change that would help could be that 'Run Main Project' action would behave the same way as 'Run Project' if no main project exists 
(you don't have to set any project as Main when creating PHP project).

Comment 4 Jesse Glick 2008-07-10 22:16:28 UTC
FWIW I use the Run [Selected] Project action all the time and it works fine.

I like David's suggestion. To put it slightly differently:

1. Delete main project concept, offer Run [Selected] Project in its place in the UI.

2. For a j2seproject with no main class - make the run action prompt the user to select either a main class or an
alternate project to run. Whichever the user chooses, persist this choice (editable later in Run panel).

3. For a WAR project etc. which is known to be part of an EAR etc., just "run" (i.e. deploy & browse?) the right
container project with prompting.

Seems simple enough. Would let us drop one mostly annoying UI concept, replacing it with a dialog which would appear
only when the IDE really can't proceed (and only for project types which might be part of a bigger system) and which
asks you something you can understand and answer.
Comment 5 Petr Jiricka 2008-07-11 07:15:49 UTC
Both Jano's and Jesse's proposal sound reasonable to me, with a slight preference for Jesse's proposal. How feasible do
you think they are for 6.5? Thanks.
Comment 6 jrojcek 2008-07-11 09:49:02 UTC
Okay, lets get rid of it.

Without the main project, each project type would have to deal with the library project scenario when the user edits a library project and wants to run some 
"main" project.

There's probably project types that don't support the library project scenario at all. For such projects, no change would be necessary. For all other projects, 
we need to design and implement proper solution. The following project would likely need to change: 

JavaSE
Java Web
EJB
EntApp client
MIDP?
CDC?
SOA
C/C++

We also need to remove the main project checkbox from all project wizards. And remove it from the Open Project dialog.

Comment 7 jrojcek 2008-07-11 10:09:24 UTC
AFAIK, project groups remember the main project as well.
Comment 8 Antonin Nebuzelsky 2008-07-11 10:11:37 UTC
Also, default scope of Tasklist (now "Tasks") is "Main project plus dependencies".
Comment 9 Jesse Glick 2008-07-11 15:32:57 UTC
I think removing Main Project is too big a UI change for 6.5 - would affect a number of things and may be risky. Milan's
suggestion "'Run Main Project' action would behave the same way as 'Run Project' if no main project exists" might be
enough to alleviate the main problem for PHP users in 6.5.
Comment 10 Petr Jiricka 2008-07-14 12:27:09 UTC
I agree, this solution would be good enough for 6.5. Would this be a change on the side of the project infrastructure,
or also in all the project types?

One caveat is that currently, all newly created/opened/imported projects are set as main by default, which makes this
change less useful. There would need to be some related changed that would make this more useful:
1. In the Open Project dialog, the "Open as Main Project" checkbox is preselected only if there exists a main project.
2. Same in the "New Project" dialog for all project types.
3. In the main project's popup menu, there should be an "Unset Main Project" action.

I would say these changes are low impact, and could be easily reverted if we don't find them practical.
Comment 11 Petr Jiricka 2008-07-14 14:43:42 UTC
> Also, default scope of Tasklist (now "Tasks") is "Main project plus dependencies".

Thanks for pointing this out, you are right. I think there is already a small (P3) problem now, I filed issue 139873.
Comment 12 Antonin Nebuzelsky 2008-07-16 17:39:07 UTC
UI Spec:

http://wiki.netbeans.org/MainProjectConceptualChange
Comment 13 Marian Mirilovic 2008-07-17 12:20:24 UTC
Increasing to P2/Def ... just to be sure it's fixed before Beta.
Comment 14 Milan Kubec 2008-07-18 16:49:04 UTC
Fixed in main: http://hg.netbeans.org/main/rev/39b1be32af9a

Comment 15 Tomas Danek 2008-10-16 15:38:34 UTC
implemented, bugs are tracked in separate issues. V.
Comment 16 Quality Engineering 2009-10-29 00:38:25 UTC
Integrated into 'main-golden', will be available in build *200910281401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/37d339c1912c
User: Jesse Glick <jglick@netbeans.org>
Log: Clarified Javadoc to describe how main project actions actually work now. (#139019, #141605,. #147962)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo