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.
The issue is motivated with issue #178090. When you have open a few files with the same name in the editor, then it's not possible to simply recognized, which file is currently edited. You can use mouse and place pointer over the editor tab and wait for a while for the tooltip, where the path of the file is displayed, but this approach is not very productive. Especially when you don't use mouse. The problem can be solved via fixing issue #178091, but it can be also solved vie a navigator bar. See the attached screenshot how it's implemented in JIdea. Basically it should be a toolbar which displays the path of the current edited file. It should be path from project, not the filesystem path. Or it should be configurable. The simple folder in the bar should be active and when user will click on a folder name then a popup window should be displayed with all files and folders inside the selected folder. User then can quickly select a file from the popup window and this file will be open in the editor. If user selects a folder instead of a file, then the navigation bar is updated with the new folder and new popup window is opened with the content of the selected folder, where user can select a file or a folder again.
Created attachment 92058 [details] The navigation bar in JIdea. The navigation bar corresponds with the project path of the currently edited file.
Hanz was willing to implement it:)
Created attachment 92059 [details] Navigation bar with opened popup window
Wouldn't it be simpler to show the file path in the status bar for a couple seconds after you switch to it? Then you do not need this special toolbar on your screen permanently. (Ctrl-Tab already does this BTW.)
This toolbar can be switch off and probably by default will be. It's one of the way how to solve the situation for web developers. On the other hand I talked with some java developers and they would like to use it as well. CTRL-TAB is described in the issue #178093 and displaying the path in the IDE statusbar is not very useful. Many people even don't notice this, because they are concentrating on the window with the list of opened files.
OK, so basically this navigation bar will duplicate the view that you see in the projects view when "Synchronize views with editor" is turned on (except for it won't be the tree but linear structure), is that correct? Note that this RFE does not help with issue 178090 at all - the nav bar displays the patch for the current file... Generally, I do not like duplicating functionality on 10000 places, even if the new place is more discoverable... It just makes the UI bloated.
It's not exactly duplication of project view, because it reflects the path for the edited file without Synchronize views with Editor has to be switch on. I don't think that the navigation bar should switch on by default. I think that this issue together with issue #178093 can help a lot. User always will see, which file is currently modified and when he need to switch to another one, then she will see it in the popup window that is displayed after pressing CTRL+TAB. Yesterday I did a change in the code, which displays the path of the file(or a part of the path) in the editor tab. The solution doesn't help very much as well, because the tabs are wide and use can see only few of them. For the rest she has to use CTR+TAB. I can publish the jar on the blog, if there will be interest to try it. I attach the screenshot of this experiment.
Created attachment 92095 [details] Screenshot of the IDE, where are two levels of folders displayed in the edtir tab.
Another thought: display the full file path in the main window's title bar, instead of / in addition to the name of the owning project.
Use main window's title bar it's very good and fast way (I think). Use navigation bar like IDEA has, is mostly bonus feature only, but may be useful.
*** Bug 155833 has been marked as a duplicate of this bug. ***
*** Bug 189294 has been marked as a duplicate of this bug. ***
*** Bug 227331 has been marked as a duplicate of this bug. ***