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.
| Summary: | Support Open Project on unrecognized directories | ||
|---|---|---|---|
| Product: | projects | Reporter: | Petr Jiricka <pjiricka> |
| Component: | Generic Infrastructure | Assignee: | Tomas Stupka <tstupka> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | dkonecny, tmysik |
| Priority: | P2 | ||
| Version: | 7.3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
|
Description
Petr Jiricka
2012-12-18 16:43:44 UTC
Accompanying this feature, there could be a context action on folders in Favorites tab called "Open as project..." The big question is how nesting is supposed to work. If a folder already belongs to a project (via FileOwnerQuery) do we still allow creating a new project for that location? When overused, people can wake up to nasty surprises.. eg. a version control commit omits some files because "Open as Project" was used on a subfolder. on the semantic level, I'm not comfortable with the label "Open as project" when the actual work done is "Create project". Can you estimate how many clicks we are capable of saving by this improvement? I appears to me that just the selection of project type in first panel, clicking next, selecting folder in second panel and the rest of the wizards has to be still shown, correct? > If a folder already belongs to a project (via FileOwnerQuery) do we > still allow creating a new project for that location? I think the answer is no - that's a clear corner case. Let's focus on the main use case. > on the semantic level, I'm not comfortable with the label "Open as project" Sure, the exact wording is TBD; we can think about a more suitable label. > Can you estimate how many clicks we are capable of saving by this improvement? This will likely differ for various project types. Also, the difference is not only in the hard number of clicks, there is also a psychological difference: some users (especially those coming from simple text editors) may not like the concept of "creating a project", they would rather just "open files". So this enhancement gives them this possibility, making NetBeans feel more "lightweight". > selection of project type in first panel, clicking next, selecting folder in second panel As for selecting folder, you mean for things like src dir, lib dir, tests dir etc? Hopefully that can be defaulted so the user just confirms it. Again, this will be simpler for some project types (HTML5) than for others (Java). (In reply to comment #3) > > If a folder already belongs to a project (via FileOwnerQuery) do we > > still allow creating a new project for that location? > > I think the answer is no - that's a clear corner case. Let's focus on the main > use case. > unfortunately people do it even now, with fairly serious consequences IMHO see issue 224790. with the feature requested in this issue it will be even easier. Please note that in issue 224790 not only FileOwnerQuery is affected but also SourceGroup instance as the wrapped project is inside the sourcecode, not just outer project folder. It's semantically unclear what will typically be the folder that people will trigger this on. I suppose it will be the Source root in most cases which in some project types cannot be equal to the project basedir (ant java projects IMHO) so we will actually have to ask users where to put the project basedir. > ...see issue 224790. with the feature requested in this issue it will be even easier. I hope not, the UI for this enhancement should not allow creating project inside or outside of another project. > we will actually have to ask users where to put the project basedir You are right, your arguments make sense. We can not rely on people selecting the right directory to start with. |