Conversation
| JFileChooser chooser = new JFileChooser(); | ||
| chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY); | ||
| chooser.setMultiSelectionEnabled(false); | ||
| File start = ProjectChooser.getProjectsFolder(); |
There was a problem hiding this comment.
This DirectoryGroupEditPanel already provides support for the Open Folder (as Workspace) functionality. It is just this complex:
Selecting File / Project Groups... menu item opens a dialog
The New group... button opens another dialog. One needs to choose Folder of Projects and Browse for it (that opens another dialog):
Only then one can click "Create Group" button. Which scans for all the projects in the given folder and opens them in Projects view (after closing all previous ones).
| public final class OpenFolderAsGroupAction implements ActionListener { | ||
| @Override | ||
| public void actionPerformed(ActionEvent ev) { | ||
| File dir = showWorkspaceFolderChooser(null, null); |
There was a problem hiding this comment.
This new Open Folder as Workspace... action provides the same function as is currently hidden in the Projects Group... dialog, but it is way more straightforward:
Just choose the new action, then select a folder in the file chooser and voilá! No change in NetBeans abilities, ... but now they are exposed to the world the way the (current development) world wants to see them
This is the second time you've selectively quoted that out of context while misunderstanding what was meant! It was when you wanted to show all sub-projects, whether open or not, in the same tree group. It is not that different to ergonomics, which is great, if/when it works. The UX is only poor when it doesn't work completely transparently. If you think it meant "expert" or that the behaviour of the IDE is different, then we're talking about two opposite things.
One of the simpler things we could do is also to default the The We could change the use of the words Project Group to Project Workspace in branding. I don't think mixing the two terms is a good idea for discoverability. Still, I'm also sceptical of doing things just because "other IDEs" do it. |
|
Bunch of good ideas, Neil!
The following seems still an open topic:
|
|
I've just had a lunch with @lahodaj and he asked me: What will happen if there is no NetBeans project underneath the "Open Folder" directory?
Let's try to provide such a functionality. TBC... |
|
Yes, I share some of @lahodaj concern there, which is partly why I think revamping Open Project is an easier first step than the Open Folder action. Although the ability to open any folder as a project is useful, and something that has come up in discussion before. Reversing the question slightly, how many of your expected use cases have a project at the folder root and subprojects within? I still think adding an option to open in a new workspace (group) on the Open Project dialog is a better approach while we work out the other use cases. Bearing in mind that dialog allows multi-select already too (could be Open Projects). Do we have an LRU ordered list for groups? Rather than an additional menu item that is likely to lead to more, what about a replacement for the current groups action - a Workspaces item that has a sub-menu with eg. New from folder.., as well as Manage and a quick list to switch between existing ones? Whatever happens here might need a rethink of the dashboard display too. I still haven't got around to next steps on that - a widget for Workspaces could be good there too. |
|
If you have a mono repo, which is just a git repo full of subprojects, it would be really nice, to open this folder as a "workspace but of course, this is just a folder with the stuff inside, I don't want to see all subprojects or folders at top level. If I checkout a mono repo to "MyMonorepo" then I can open MyMonorepo as Projectfolder with all the stuff inside. MyMonorepo is the worksapce then w/o being a specific netbeans project but just a wrapper around it, to open it as a project. |
| } | ||
| if (fo != null && fo.isFolder()) { | ||
| try { | ||
| Project p = ProjectManager.getDefault().findProject(fo); |
There was a problem hiding this comment.
- This change makes sure the "top most folder" of each
DirectoryGroupis visible- e.g. the folder selected in Open Folder as Workspace is always visible
- thanks to Show nested projects co-located and indented #9602 the "top most folder" is the first project in the list
- ... as it has the shortest path and all other projects are nested
- if the root folder is recognized as a regular NetBeans project...
- ...then the behavior is the same as it was by now
- if the root folder isn't real project, a
GenericPrjis created for it - if there is no project beneath the root folder, then one gets just a simple "files view" of the root project:
There was a problem hiding this comment.
- in case of NetBeans (where the root folder isn't a project)
- unless something like Nesting Projects by their Cluster #9624 is implemented
- it all looks like this right :
- btw. the list of projects is pretty long as it includes all the testing projects found in the NetBeans codebase
- but that's how it always have been ...
- ... no change in that
- just nobody really tried to use "Open Folder as Group" yet ...
mbien
added
the
ci:dev-build
|
I get that this is in early stages but I would probably not rebrand project group to workspaces. I think "Add Folder to Group" would be a small/self contained feature to explore / merge independently which could be built on top later if needed. PGs are a core concept of NB and part of API, online docs/blogs (LLMs*) and even CLI flags. I do also like the name, since it is self describing - a group of projects, no matter if related or not or if they share the same parent folder or not. This is not the same as the classic eclipse workspace for example. Also: naming is hard I also think that automatically opening an unspecified amount of projects isn't a good idea. The first thing I did is to open *got curious so I asked 4 models to compare PGs with eclipse workspaces and the results were fairly useable e.g excerpt of the summary, I think that one was Mistral: DetailsKey difference in philosophy Eclipse workspaces are structural containers — they fundamentally partition your development environment. Switching workspaces means a fresh Eclipse instance with different settings and projects. NetBeans project groups are organizational shortcuts — they're a convenience feature for opening related projects together within a single NetBeans session. Your settings, plugins, and instance remain the same. |
|
Am 23.09.2026 21:08 schrieb Michael Bien ***@***.***>:mbien left a comment (apache/netbeans#9631)
I get that this is in early stages but I would probably not rebrand project group to workspaces. I think "Add Folder to Group" would be a small/self contained feature to explore / merge independently which could be built on top later if needed. PGs are a core concept of NB and part of API, online docs/blogs (LLMs*) and even CLI flags. I do also like the name, since it is self describing - a group of projects, no matter if related or not or if they share the same parent folder or not. This is not the same as the classic eclipse workspace for example. Also: naming is hard
I also think that automatically opening an unspecified amount of projects isn't a good idea. The first thing I did is to open ~/NetBeansProjects as "workspace" and it crashed NB right away. The other reasons are on the nb private mailing list. Once the Folder is added, it is easy to open the projects within it.
*got curious so I asked 4 models to compare PGs with eclipse workspaces and the results were fairly useable
e.g excerpt of the summary, I think that one was Mistral:
Details
Key difference in philosophy
Eclipse workspaces are structural containers — they fundamentally partition your development environment. Switching workspaces means a fresh Eclipse instance with different settings and projects.
NetBeans project groups are organizational shortcuts — they're a convenience feature for opening related projects together within a single NetBeans session. Your settings, plugins, and instance remain the same.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.Message ID: ***@***.***>
|
4 participants
Motivation
Being for Experts
NetBeans has a unique concept of handling projects. It is a completely different workflow than other IDEs are built around. I like it because it is flexible. However it also complicates things - because it is flexible. Projects are stored in Git repositories these days. When opening such a project, it (almost all the time) makes sense to open all the projects in the Git repository. That's not a NetBeans philosophy. NetBeans allows one to cherry pick and open only some of the projects.
Being Different
Such a flexibility makes NetBeans an IDE for experts. However it also comes with a cost. Not only implementation wise (IDE has to be ready for set of projects being "half open"), but also from a UX perspective.
Every "expert" has different set of subprojects open and then the behavior of the IDE is different. Such a "magical flexibility" makes the UX poor.
Other IDEs have a concept of workspace. When opening Apache Maven sources in a "workplace", then the IDEs just open all the nested projects in the Apache Maven Git repository.
Simplify UI. Keep Flexibility.
I believe the time has come to straighten the NetBeans IDE position by adjusting to common UX while keeping the flexibility under neath. NetBeans already has a support for groups of projects. Just the UX feels old fashioned and like a second class citizen. I'd like to improve the UX by using the same infrastructure to mimic the concept of a "workspace". Ideally I'd like to rework the File menu to offer Open/Close Folder, Add to Workspace, Save Workspace as just like VSCode File menu provides.
TL;DR
Experts "in the know" can still Open Project... one by one and work only with a properly curated and selected subset. However for clueless users working on an unfamiliar code base, I believe we have to lead the UX towards open all the projects at once.
That is the outline of my plan.