On 10/2/26 12:22, Anton Epple wrote: > When asking “Central Mankind Brain” you should always ask the "Great Teacher" > Alois Drahoslav Drchlík for a second opinion ��. > > I think it makes a lot of sense to limit the scan depth, stop descending once > a project marker is found, show results as they come in, and offer a Cancel. > Finding projects is cheap. Opening them (classpath, indexing) is what hurts > with the repos Matthias listed. > > For the "UI tweak", I think we already have the pattern. Maven parent POMs > show a "Modules" node, and Gradle shows "Subprojects". Both list child > projects without opening them, and you open one with a double click. Users > understand that. > > So Open Folder could: > > 1. open only the root folder (as a real project, or as the fallback from > #9650), > 2. show a "Projects" node under it, filled by a background scan, nothing > opened yet, > 3. offer "Open All Projects (N)", which opens directly below a configurable > limit (as suggested by Sven) and asks for confirmation above it, > 4. optionally, read a .nb-workspace.json (your option A) to preselect what > gets opened.
tbh I am a bit confused why there is such big focus on trying to automatically open everything within a folder (it might be distracting from the actual underlying improvements). It is easy to demonstrate that it is a very bad idea to try that performance wise and likely security wise too. (performance PRs are welcome btw if backed by measurements) I have a pg with all NB modules for situations when I do larger cleanups - you don't actually want to open everything unless there is no way around it. Even a cluster would be too much. Please try it and hit find usages or run a refactoring/code inspection while everything is open. Going through the file tree isn't even the problem. Any of my project folders would already crash NB as flat list before going deeper (its one of the first things I tried when playing with the POC). We do already have a checkbox for compact java files (see properties) which opts-into scanning, otherwise a student would scan their whole home folder if a java file is in the root. lets try to focus on something small which can be extended later: The minimum viable product of this is being able to add folders to project groups. As sub folders and/or as base folder of the group. Those folders may list projects (or anything else, potentially filtered), and the user may open or close those projects, one by one (double click already works, select multiple and open works too obviously) or in bulk (open contained projects actions or similar to the mvn open all subprojects action). If we still want an auto-open feature for project groups, lets make that an opt-in check box of the added pg folders (not recursive), analog to the already existing "open required projects" of the open dialog. UI entry point wise it would have small surface: - (Create pg from currently opened projects is already there) - A new option would create a pg from a folder. This would simply add the selected folder as root folder to a new pg - it may or may not have projects already - Another action with "add folder to pg" could be added too (this is essentially the core function where everything else is based on). future / discoverability: Instead of starting with the "none" pg, NB could set the default project dir as pg root folder on first launch. more UI: the Projects view has a severe lack of a (collapsible) toolbar as used for the Debug, Navigator or Hierarchy views -> some actions could be moved into that. Toolbars are self documenting features. -mbien --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
