On Tue, Oct 6, 2026 at 11:58 AM Michael Bien <[email protected]> wrote:
> 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) > My personal opinion: If a user explicitly says "I want to work with stuff in this folder" (e.g. by opening it as a project/"workspace folder"), then we should try to make things work for them. In practice, that means indexing the stuff in the folder (some things work reasonably with on demand indexing, but not all), and project open is a way to make sure indexing happens. If we let the user "open" a folder, but don't index, and force the user manually select which projects should be open, then I am not sure how big an improvement is that compared to the current state. The user could already open the projects (if they exist). Yes, for big projects (like NetBeans), opening and indexing all is unlikely to lead to good outcomes. But for many smaller projects, the outcome might be better than the current state. One possibility that comes to mind: when the user selects a folder, we can go through it and discover projects and/or files. If the number of projects is reasonable, we simply open them. If the numbers seem a bit too high (like for NetBeans), we don't open the projects, and show some kind of a warning telling the user working with the whole folder at once might be problematic, and whether they really want that, or whether they want to select individual projects. Of course this is a heuristics, but I hope we could get to reasonable outcomes with the heuristics. The fallback/last workaround for the user is always to not open the folder, but open individual projects. I would say, if we could make things work for projects like Helidon (and, if possible, OpenJDK), it would be great. Admittedly, there are currently some sharp edges. (Jaroslav also has some idea that would make things work better specifically for NetBeans sources, but that's fairly specific for NetBeans.) Jan > 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 > > > >
