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.
For users that are very keyboard oriented, it would be very very valuable to be able to quickly open a file from the project using just the keyboard from any context in the IDE. Here is the kind of solution I'm imagining: User is working somewhere in the IDE, and knows they need to open the Foobar file. They type Ctrl-Alt-Blah and a window appears where they type "bar" and any files in the project that have that string in the name appear in a list, with the first selected. If the user presses enter, the file is opened in the editor (if already open, it would be fronted). The point here is that a user should be able to get a file open with only a couple keypresses of overhead and some minimal part of a file name. No mousing, no scrolling, no reading. Just a quick keyboard sequence.
There is already the Alt-Shift-O (Fast Open) feature to open classes quickly.
Yes, but that only works with java classes.. It doesn't work for xml documents, nor jsp's, nor c++ files, nor makefiles, nor ant files, nor html files nor css files... etc. The need is for something that operates on any kind of file.
1) Please stop filing bugs like this agains projects. It has nothing to do with projects at all. 2) There already are some ways. a)Jesse's Alt+Shift+O b) Press Ctrl+1/2/3 whatr ever your preference is Project view/Files View/Favorites start typing find the file press Enter c) There are also shortcuts which will locate the current file in the views in case you know that the file of your choice is somewhere near
I think this is a valid and useful feature request. I am not sure what module it really belongs to. An example of possible realization of this feature request is IDEAs "Go To | File..." main menu action. I remember at least one IDEA user mentioning this feature during the usability study (and trying to find it in NetBeans).
Obsolete target milestone, changed to TBD. Please re-evaluate.
*** Issue 41967 has been marked as a duplicate of this issue. ***
This is what $NB_SRC/contrib/filesearch module does ("Go to File in Project Action" on AutoUpdate center). I find it very useful even when developing NetBeans modules == Java. Andrei is current maintainer(CCing) AFAIK. Would be great to have this module part of official NetBeans release. > 1) Please stop filing bugs like this agains projects. It has nothing > to do with projects at all. I did not take a look at the module sources, but I think it is kind of project context's sensitive. > For users that are very keyboard oriented, it would be very very valuable True. It was very easy to get addictive to the module :)
Yes, it only searches in the current project (the one whose name is displayed in the title bar of the NetBeans window). The main reason for not searching in all open projects is that it wouldn't scale well if there were many of them (which is often the case at least for me).
A few comments on this one from a long-time Eclipse user now on NetBeans 100%... - This must be included in NetBeans as soon as possible. I know Eclipse users that will simply not move without this features. It's been very painful for me to not have this one too. - filesearch is 99% of what I need, but isn't quite there for reasons I'll mention below - until you've used this features regularly you don't realize how important it is. It's especially useful when you start dealing with large projects that have a lot more than Java in them...Open Type is no longer enough... So then, filesearch. It works like it's supposed to, though I'd like an option to work across projects. But it's super slow, and I guess some have thought that making it work across projects would be even worse. I don't think this is the case. In order to support this features, you need an up-to-date index of files in the project. Eclipse does this by hooking into platform-specific directory update hooks, which NetBeans obviously can't do. However I think the following strategy would scale ok: - Build up the index at some point based on current files - Record directories encountered with their modification times - When scanning for changes, only scan for changes in directory modification times, which indicates files have been added or removed. There's no need to re-list all files in the system every time, and only scanning directory modification times will take far less effort. Perhaps filesearch does this now and I don't know it, but if it were keeping an index in memory it shouldn't be as slow as it is (15s the first time for me...maybe 7s per search after that). So is anyone owning this? Is it going to be included? I think we need a "yes" answer to both, because this is actually a feature lots of people will miss if it's not there.
A separate search for files, types, text in the current document and text in all project files..... is a litttle bit like the award winning dog asking questions (http://secretgeek.net/ms_search.asp): * So you'd like to search for something! * Do you know where you last saw it? Yes or No * Is it bigger than a breadbox? Or smaller * Is it animal, mineral or vegetable? * Maybe you should buy a personal organiser! Then you won't keep losing things. * Did you check under the bed? I think maybe we need a search action that would unify Goto Type (for all known types), Goto File (in all open project) and Find In Projects (for full text). We are adding a Search in Files capability and greatly improving the (Java) Goto Type in 6.0. Now we only need to add the capability of Andrei's plugin and integrate them all into one usable interface.
Hmm, can someone tell me what this issues has to do with editor? Please.
Add those 14/7 seconds) Please specify what project did you search through. If you just say time and not the size of the project it is not very useful. Thanks.
It was the JRuby project, which contains: 1562 files 192 directories After a build, it contains: 3468 files 255 directories This seems relevant since the plugin appeared to be indexing built files and directories too (which seems odd, since those files get wiped out during a clean...why index them?) In both cases it seems like building an index once and then scanning dirs for modification time would scale reasonably well.
Checked the modifyied module into branch: bug44586_experiment_03_2007 Feel free to test it. Should be faster and look more as Go To Type, However be aware of the fact that it is not finished. Performance on my computer, with lot of stuff open: First search: SEARCH TIME : 14463 FILES SCANNED 15465 Subsequent searches: SEARCH TIME : 1232 FILES SCANNED 15465 SEARCH TIME : 977 FILES SCANNED 15465 SEARCH TIME : 493 FILES SCANNED 15468 SEARCH TIME : 1784 FILES SCANNED 15468 SEARCH TIME : 319 FILES SCANNED 15468 SEARCH TIME : 321 FILES SCANNED 15468 Known bugs: 1) Project only does not work searches all opened projects 2) Some files can't be open (e.g. class files) 3) Doubleclick in the list does not work 4) Case Insens. works only after you modify the search criteria 5) No wrap around 6) Subsequent searches can be faster 7) No caching yet 8) No indication of search or no files found 9) ... lot of other stuff
I did a bit more cosmetics work, committed to Hrebejk's branch: a) Added a Location field so it looks even closer to Goto Type b) Dbl click and Enter key both open the file (hrebejk's issue #3) I really do not miss Hrebejk's issue #1, I'd prefer to search in all projects and remove the option. Plus it'd be consistent with Goto Type. src/org/netbeans/modules/accelerators/filesearch/FileDescription.java; new revision: 1.1.2.2; previous revision: 1.1.2.1 src/org/netbeans/modules/accelerators/filesearch/FileSearchAction.java; new revision: 1.2.14.2; previous revision: 1.2.14.1 src/org/netbeans/modules/accelerators/filesearch/FileSearchPanel.form; new revision: 1.2.2.2; previous revision: 1.2.2.1 src/org/netbeans/modules/accelerators/filesearch/FileSearchPanel.java; new revision: 1.3.2.2; previous revision: 1.3.2.1
I concur with pbuzek on hrebejk's issue #1; across projects is the correct default behavior, so long as they're clearly demarcated. A potential idea for you all would be to do it like Eclipse, where the dialog has two lists, one for projects and another for per-project results. It brings up results for everything, but you can narrow it by tabbing to the project pane and up/down to the project you want. The complication I'm worried about is when you have multiple instances of the same project checked out (multiple branches, experimental local copies, etc) and want to narrow things down a bit.
Not having #1 quite limits the ways in which you can use the dialog. Most often I use it to quickly open the project.xml or project.properties file of the current project. I often have more than 100 open projects, so searching in all of them and then scrolling to the right file would slow me down considerably. The reason I used FileObject's, although I expected them to be slower than File's, was that I could make use of VisibilityQuery.isVisible(). Hrebejk's implementation doesn't use VQ and thus it displays CVS files in the search results. Of course, VQ has performance implications if done for all files matching the name, so this issue is a tricky one. I would also prefer that the module not be merged into contrib/filesearch's trunk at least until it provides a superset of the current trunk functionality (i.e., the ability to search in the current project only and to skip the non-visible files).
OK, VisibilityQuery is TBD. Doable with lazzy list I guess. We were talking with Andrei over phone and he said there should be no chackbox for VQ. However I think when is called "Show Hidden Files" then it might work. For scope. I think it should be radio (o) All Projects (o) Main Project (o) Curren Project I updated the form. Don't expect it to work yet, it is just mockup of how it could look like. Checking in FileSearchPanel.form; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/FileSearchPanel.form,v <-- FileSearchPanel.form new revision: 1.2.2.3; previous revision: 1.2.2.2 done Checking in FileSearchPanel.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/FileSearchPanel.java,v <-- FileSearchPanel.java new revision: 1.3.2.3; previous revision: 1.3.2.2 done
For record: Issues by Andrei. 10) GTF does not work well when regexp characters are used in the searched text. 11) VisibilityQuery
For VQ: see issue #95974, which could be prioritized. (Probably easy to implement.) I needed it also in the recently created IncludeExcludeVisualizer. As a workaround I just copied the default regexp from MasterFS, on the assumption that this setting is rarely modified anyway. Caching could use CacheDirectoryProvider. I hope no one minds if I move this to the projects component. It's not an editor issue, really.
If GTF supports searching all three options, I think there should be a way to set a preferred default (pretty good) or have separate key bindings for the different ones (at least "All" and "Current"). All is generally good enough for me, but I understand those who are working with a filename that extends across a lot of projects.
Increased the spec version number on the branch to 1.1. Checking in manifest.mf; /cvs/contrib/filesearch/manifest.mf,v <-- manifest.mf new revision: 1.1.22.1; previous revision: 1.1 done
Headius: IMO the eclipse UI does not solve much with the 2 lists - you still have to select between all the locations of a file with a common name (project.xml, Bundle.properties, ..) and it adds another TAB to switch to the second list. We might as well put all the items in the first list and you can select there. In other words e5e UI does not solve Andrei's use case. Hrebejk: I think the distinction between main project and current project (even if we append the project name to these radio buttons) is esoteric for most users. Maybe we should leave out the main project and just go back to the checkbox with something like "[ ] Only in MyFirstJavaProject". Searching all projects should be default, in any case.
Yes that certainly possible. However there is another problem with that. I think I know what will HIE/Jano say: NetBeans does not operate with current project. See build/run actions everything bound to main project. So if something is esoteric then the "current" project (which it is a bit, considering the way how is it determined). So Jano might suggest: All or Main, which in turn does not satsfy the needs of the main usecase. Hmm, just to make it a bit more complicated, but don't be sad neither you or me are the right persons to solve it. Leave it as it is, we'll consult with Jano when implemented.
Test and Generate Javadoc actions are sensitive to the selected project and ignore the main project. The main project concept should be used sparingly.
I tried it, and it's really fast, but I ran right into the same problems others are having: There are a million Bundle.properties and layer.xml files, which I'm often wanting to jump to. What if we simply bubble the match from the current project to the top? The list still shows ALL projects, but I don't have to go hunting for The Right One. For extra credit, use a list cell painter which places a line between this match (or set of matches when it's not unique) and the rest of the matches.
tor: that would probably work, but it still needs to make sure that I don't have to wait until files in all projects have been scanned even when I'm just interested in files from the current project. Perhaps the search could be first applied to the current project (and the results displayed immediately) and then to all other projects (and the results appended). phrebejk: the name of the current project is always (I hope) displayed in the title bar of the main window, so there is nothing "esoteric" about it. IMHO, that is. As to who's the right person to solve this: I feel we, who use the IDE for several hours daily, have a lot to say about what it should do. It is likely that other users will do work similar to ours, so our input should be listened to. This is not to say HIEs should not be involved, of course.
Tor's solution: 1) Does not solve the speed proble as Andrei mentioned 2) Would be really confusing if there is more items from the current project than the list can display at once. 3) Is not standard at all Sparse usage of main: :-) Javdoc is project dependent, OK other prject action are bound to main and they are probably more important. But I'm not against dropping the main from the list Project name in title: NO, does not make sense as the dialog is capable (and currently only) searching all projects Isn't it interresting? Buzek says that he does not like the radio button and everyone has an opinion. Maybe there are more appealing problems to solve in the IDE. I know about some really cool P1s :-)
1/speed: I don't think we should solve this by making the user go to extra trouble. After all, I'd rather wait an extra 3 seconds for a search than spending three seconds to move my mouse up and switch to another tab or search setting. Bseides, we need to make this really fast anyway. Code completion deals with large result sets and we're providing nearly instant results. If necessary we should stash file indices in the project private areas or something. 2/usability, 3/standard: I think there is a LOT of precedence in providing more relevant results first. I could have sworn I even saw NetBeans code completion doing something like this with a separator line, but now I can't find what it was. In addition to sorting the results by project (with current project getting precedence), we should probably also take editor stack depth into account. In other words, files I've opened recently should have higher precedence.
1/ Speed. I really like these or somethings. What exactly do you mean? :-) Indices atre problematic. Means to listen on whole filesystem and trying to keep up to date. May potentially take lot of memory. But if someone wants to provide the implementation he might go and copy RepositoryUpdater. Causing user trouble: Is a redio button a reall trouble? 2/3/ No there is not lot precedence except CC. And that's good. If you have a find dialog it finds something it is sorted alphabetically. Would you expect there is another section below. No you wouldn't. Sorry this is not a good way how to make UI. 4/ Editor stack. No. There was long discussion about what should be the sort of project in the projects tab. Alpha or by time of openning. Anything what has to do with time is unusable. None keeps track of what he opened when. And try to find something in it then. BTW what would that good be for? Just press Shift+F4 if you want to go to opened document.
When I was talking about search precedence I was thinking of applications optimized for search - such as Spotlight on the Mac. Imagine Google sorting search results alphabetically ;-). Regarding editor stack: I don't care strongly, but it seems like a good idea to me that it should at a minimum be aware of open files and prefer those first. I'd like Goto File to be a good replacement for Open Type and Open Document; I shouldn't have to think about whether the file is already open, or whether it's a type or some other type of resource. For that reason, it would be nice if it made it easy to jump to my current files. Perhaps we should just defer that issue until we do something Mylar-like.
> Would you expect there is another section below. No you wouldn't. Sorry this is > not a good way how to make UI. You might take a look at Eclipse "Open Type" (C-S-t). It shows recently opened files before any other matched result separated by nicely visible separator. n of recently opened files are shown always even without filling the filter. Kind of combination of our S-F4 and A-S-o. I've found that pretty useful. I choose in 50-80% (?) from the recently opened files without filling the filter (often one letter helps). Best to play with it for a while to feel it.
And what happens whenthe separator is not nicely visible? E.g. too many files open. I proposed to show opened documents when the search text is empty for GTT (A-S-o) but was told it is not good idea. For GTF it could work better. Good idea then, as Tor says, we could save the thinking about whther it is open or not. Tor: I know there was a smile in the sentence. But just for record in Google you don't search by the name of the document. Right?
And stop throwing bad UI ideas on me if you want to have at least some implementation. :-)
> And what happens when the separator is not nicely visible? E.g. too many files > open. You just press the first letter of what you are looking for (BTW it also shows recently opened files, not just currently opened files). Also you might show just e.g. 10 recently opened files which would be always visible together with separator.... As I said, the best is to try it for a while, better than discussing about it :)
Showing more relevant results first is a *very good* idea. As Martin mentioned, Eclipse does this...and the reason this I've taken a big interest in this issue is because I'm sure Eclipse users are going to miss the feature if they try to move to NetBeans. If they move and the feature is present but substantially less useful (i.e. not showing most relevant results) then we're not going to keep them. You really need to try it before you can discount it, it's fantastically useful. Also, code completion/go to type does attempt to show the most relevant results...by showing results in imports and current package in the normal dialog. So saying that showing more relevant file results is a bad idea ignores the fact that other searches are *already doing that*. I would even recommend more contextual smarts, as Eclipse does...if I'm completing a method that's assigned to a typed variable, show me results that will return that value at the top of the list. If I'm a catch condition, only show me exceptions. But that's a separate issue. Eclipse is successful for good reason: they're really listening to the users of the product and trying to add what makes them more productive, and showing more relevant "go to file" results first is extremely helpful. It also neatly solves the question of whether results should show all projects or current project...show current project and recent files first, and allow access to other projects with a few additional keystrokes (tab, up+down). When Eclipse does this, nine times out of ten the current project results are the ones I want...but if I couldn't get at the files I wanted that tenth time, I would be extremely frustrated. And don't ever, ever, ever require a developer to use the mouse, and ideally avoid making them use any keys not immediately under their fingers.
"If I'm completing a method that's assigned to a typed variable, show me results that will return that value at the top of the list." -- NetBeans already does this (in recent builds). This is what I referred to earlier when I said I could have sworn NetBeans does some completion filtering, separated from the rest with a line. I discovered afterwards that this is the precise scenario when it bubbles particular matches to the top.
"If I'm a catch condition, only show me exceptions. But that's a separate issue" Obviously NB does this as well. And yes there is a separator in the CC of NetBeans. First the smart items then all items. For some strange reason I know a lot about these featues. Could someone do me I favor. I Asked 3 times and I always get a response like eclipse does this and this and it is wonderful. This is cool but does not help much. I admit I'm stupid, but I cant find all the wonderful features in ec 3.2. 1) Which version of eclipse do you use? 2) Which feature you use. Please use names of the menus not the shortcuts. (And how do I enable the feature? The wonderful GUI of EC has most of the action disabled, probably by some perspectives or what) 3) Most important. What happens when the list of features which fit most is longer than the visible part of the listbox> Others are not shown and users have to know about it? 4) Are there any volunteers to implement these "smart" things when I do the rest?
>Could someone do me I favor. I Asked 3 times and I always get a response like >eclipse does this and this and it is wonderful. This is cool but does not help >much. I admit I'm stupid, but I cant find all the wonderful features in ec 3.2. Spend a week using only Eclipse to do all your Java development :) >1) Which version of eclipse do you use? I have used it since around 2.0, but this feature has been around as long as I can remember. >2) Which feature you use. Please use names of the menus not the shortcuts. (And >how do I enable the feature? The wonderful GUI of EC has most of the action >disabled, probably by some perspectives or what) The feature is enabled by default and globally accessible (if you have projects...I assume it doesn't work if you don't have any files). I don't know the menu option or toolbar button mainly because a menu option or toolbar button probably don't exist for this. Productive developers don't generally use the mouse. I do know that it's Ctrl+Shift+R on most systems and Cmd+Shift+R on Mac, and that the function is called "Open Resource" or something similar. Start it up, check out a project or two, and try it. >3) Most important. What happens when the list of features which fit most is >longer than the visible part of the listbox> Others are not shown and users >have >to know about it? Scrollbars! :) Seriously though...there's going to be many cases where there are more results than expected, but if users don't see what they're looking for and there's a scrollbar there, they'll scroll (or arrow key down). But in my 4+ years using Eclipse exclusively I almost never had to go to those other results. It was that good. >4) Are there any volunteers to implement these "smart" things when I do the >rest? I'd love to help in any way possible, but it will certainly take me a little time to come up to speed on how NB works internally so I'm not duplicating features or services. I did look at the original code for this feature and was able to understand basically what was going on, but I'd need help going beyond that and making changes.
Created attachment 39460 [details] eclipse GTT and GTF
*** Issue 99496 has been marked as a duplicate of this issue. ***
Just to add a little fuel to this fire...Eclipse's "Open Resource" dialog finds the files I'm looking for instantly (or nearly instantly), so any delay, including the current 5-10 second delay in the Update Center version, is very visible and painful for an ex-Eclipse user. Another item...it appears to restart the search fresh every time I stop typing, even if it's already scanned once. So if I have a typo and backspace over it, there's another 5-10 seconds of waiting for results. And finally...even with 5-10 second delays it's quicker than me trying to dig through a file tree...and I usually just suck it up and wait. This feature is *that* important to me, and any perf improvements would make me very happy indeed.
Just FYI - the update center version is -not- the version Petr has been working on in a branch; last I saw there were objections to integrating his branch into the trunk (see abadea's comment).
So where do we stand on this? I vote for Petr's faster version to get merged in and into update center ASAP. I think I waste about 5-10 minutes a day on the slow version, and I really would like to have the fast version as soon as possible. Has this one stalled? I don't know that the existing version is really practically usable because of the speed issues. I'd rather have 20 versions of a file come up immediately (across projects, which I believe was the primary objection to merging the changes) than one version (single project) come up after waiting 15 seconds.
Right now I don't have time to do work on it. Hopefully sometimes later. If you need the fater version you can check it out and buid it.
FWIW, I use the "slow" version daily and I've never needed to wait 15 seconds for the results. This is of course not to say that Hrebejk's version is not faster. But the "slow" version is still more useful for me -- I use it mainly to quickly open project.(xml|properties) and resource bundles. If you really want to have Hrebejk's version on the UC, that's fine. Anyone can always fork the code and put it to another directory in contrib on anywhere else and continue the development there. contrib/filesearch can be deprecated when its functionality is provided by the new module.
Based on the P2 priority and TBD target milestone it seems to me that this issue is still not given the priority it deserves. Take for example a typical medium size web application using Struts/Spring/Hibernate. You might have tens if not hundreds of JSP pages, dozens of Hibernate mapping files, half a dozen configuration files, a few CSS files and various XML files for things like DBUnit. You need to edit these files fairly often, almost as often as Java files. NetBeans, out-of-the-box, is not a very attractive option for such scenario, and it certainly isn't a particularly rare scenario (in fact, quite the opposite).
We're a software company, where all developers use Eclipse. After attending Sun's Netbeans World Tour event, I was impressed and came back eager to see if we could switch to Netbeans. So I got a couple of volunteer developers to start using Netbeans. Within the first hour, they started complaining about this missing feature (compared to Eclipse). And the next day they switched back to Eclipse, because "Netbeans was unusable". In my opinion, Netbeans has a lot of high-level features (GUI editing, Java EE mgmt, etc) that I'd like us to utilize, but as long as Eclipse is superior in the low-level, day-to-day work, the developers will stick with Eclipse...
abadea: I would very much like the faster version on UC, since I really don't have time to build contrib stuff (nor would I want the hassle of rebuilding when I upgrade to a new milestone, for example). The bottom line right now is that the "slow" version is slow enough that it's faster for me to go to a command prompt and open VI than either use it or traverse the file tree myself...and that's a rough position to be in. As an example, try to imagine if it took 5-15 seconds every time you wanted to Go To Type. How frustrating would that be?
I did some improvements in the branch. Lot of thinks still do not work. I started continuous build at: http://deadlock.nbextras.org/hudson/job/go%20to%20file/
phrebejk: oh, thank you so much for the hudson build!! The modified version is very nice, and takes no more than a second to list all files in all locations. I'm very happy with this. Someone should blog this and let the community decide which version should go in. For the others on this bug, give it a try: download, Update Center, install downloaded nbm. It's excellent.
Which version this plugin runs? I try install this on nb 5.5 and it is not possible. There is any possibility to a backport for 5.X versions?
Wait. It's buggy like hell. I did not have time yesterday to mention all the bugs I know about: 1) Check boxes do not modify the current result. One has to do the search again 2) There should be some info about searching and nothing found like in GTT 3) If you choose not to show hidden files it only works half. Means if the file or its immediate parent folder are invisible it works if some upper directory is hidden it will still show the files (I.e. works fine for the CVS folders but it may fail in other cases) 4) Performance can be improved when the new search is subset of previous one there is no need to rescan the folders, but the current implementation does. Ad porting to 5.5. May be possible but I have no time for it. I recommend to use 6.0. Will see whether we can somehow push this feature into the standard 6.0 distro. I hope we can.
In the meanwhile, why don't we just fork the branch to, say, contrib/gotofile, and don't add it to the daily build of alpha NBMs? That would make it more visible than the build on Hudson. I can set it up if no one else has the cycles.
Are you still againt merging the branch into trunk of the module? Why? I did everything you asked for.
Sorry, I hadn't looked at your changes, it hadn't been clear to me that "some improvements" were addressing my comments. It looks better now, but there are still some (from my point of view) regressions: - I don't want to search in the *main* project, but in the *current* project. Yes, I know: if this goes into 6.0 I guess I will have to fight a long and hard battle at least with HIEs to get the concept of current project exposed in such a visible dialog. - nested projects are not ignored. If I e.g. search for project.xml in the db module, it also finds the project.xml's of all modules under db. But it seems your version is still more popular, and I don't want to be a blocker. If you want to merge the branch to the trunk, go ahead. I have already tagged the trunk with a "before merge" tag.
Aha I think we had the conversation about whether main or current and as far as I remember most people voted for current. It is really easy to switch so I will do it and we'll see. Ad projects under project) If you know how to do it without hurting the performance too much we can try. However I think that this is a minor issue and it does not impact too many people (except NetBeans developers of course).
I don't see a fast and correct way, but it might be enough and not too slow to just skip those direct children of all TYPE_GENERIC SourceGroup's which are not SourceGroup.contain()-ed by that SG. Doesn't handle all cases, but still better than not handling any cases.
For main vs. current project, see my comment of Mon Mar 12. Use of SourceGroup.contains() on TYPE_GENERIC groups is indeed the proper way to select which files should be considered.
It looks like we ask the user to specify scope for search (main; current; all) to workaround the following problems: 1. peformance - smaller scope means faster results; 2. number of results - e.g. too many results called "Bundle.properties" don't help the user to find the right one; I do think that we should *not* ask the user for the scope and always search through all open projects. We should try other approaches for addressing the mentioned problems. My proposals: To address problem #1 I would suggest to start searching in the place we expect contains the searched file. For example the current project could be a good starting place. As soon as we have a matching result, we should show it while indicating the search is still in progress. This way the user can get the current project results sooner. To address problem #2 I would suggest to use the search text field itself where the user can refine searching criteria. For example typing "bundle core" would filter only those "Bundle.properties" located in "core" project or having "core" in its path. I think this would work very well for files with the same name. For example, if a "core" project is the current one and I type "bund" the results should show up immediatelly and it should select "Bundle.properies" file from the core project and maybe even fromt the "current package" while adding more and more results from other projects. The user can either hit Enter or move up down as the results are ordered by name and location so the core project results are next to the selected item. If the user actually wanted to open a bundle file from different project, she can either use up/down keys to find it in between the results or type "bund java" to filter the results from the java project only.
1) Not true. It works as you ask for. We always search all projects when the checkbox is checked. Those from main/current project are first in the list and have slightly greener bacground. 2) Not necessary. Name of the project is shown in the listbox and the actual location is shown in extra field. To check the current fuctionality please install the NBM from deadlock.
The "bundle core" example ignores one fact: I usually only type 3-4 characters of the file I'm looking for. Imagine having a file like "default.properties" in multiple projects. If I wanted to filter to a specific project I would have to type "default.properties <project>"...I'd wager that most people would just type "defa" and down-arrow to the file they're looking for. I know I would. It would have to be more than 15 down-arrows to get to the right file for it to be worth it for me to type out the full filename.
Sure. Typing "bund co" would show files starting with "bund" and located in projects starting with "co". The goal is to eliminate any kind of scope selection in the dialog whether it's a check box or radio buttons which I think is not necessary. Note I haven't tried the module yet, so I don't know how exactly it works. I just assume there's some sort of scope selection which I think should be avoided.
As I alredy said the checkbox does not influence scope. It is just about sorting. Please test the functionality. I'm thinking about adding such a checkbox into Go To Type too.
I love the hrebejk version exactly how it is (with regards to scoping) and for what it's worth I'll never be unchecking that box. As far as I'm concerned, the hrebejk version has checked off one more "wish" from my list.
Some changes done on the branch: Fixed 1) Check boxes do not modify the current result. One has to do the search again 4) Performance can be improved when the new search is subset of previous one there is no need to rescan the folders, but the current implementation does. X) Went from main project to current project (name of the project top prefer is shown in the checkbox text. Checking in FileDescription.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/Attic/FileDescription.java,v <-- FileDescription.java new revision: 1.1.2.4; previous revision: 1.1.2.3 done Checking in Bundle.properties; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/Bundle.properties,v <-- Bundle.properties new revision: 1.2.14.3; previous revision: 1.2.14.2 done Checking in FileSearch.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/FileSearch.java,v <-- FileSearch.java new revision: 1.2.14.2; previous revision: 1.2.14.1 done Checking in FileSearchPanel.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/FileSearchPanel.java,v <-- FileSearchPanel.java new revision: 1.3.2.6; previous revision: 1.3.2.5 done Checking in ListListModel.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/Attic/ListListModel.java,v <-- ListListModel.java new revision: 1.1.2.2; previous revision: 1.1.2.1 done Checking in SearchWorker.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/SearchWorker.java,v <-- SearchWorker.java new revision: 1.2.14.4; previous revision: 1.2.14.3 done Checking in RegexpFileFilter.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/Attic/RegexpFileFilter.java,v <-- RegexpFileFilter.java new revision: 1.1.2.2; previous revision: 1.1.2.1 done Checking in FileSearchAction.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/FileSearchAction.java,v <-- FileSearchAction.java new revision: 1.2.14.4; previous revision: 1.2.14.3 done What remains: 2) There should be some info about searching and nothing found like in GTT 3) If you choose not to show hidden files it only works half. Means if the file or its immediate parent folder are invisible it works if some upper directory is hidden it will still show the files (I.e. works fine for the CVS folders but it may fail in other cases) 5) Not show files from subprojects
Should ignore subprojects. Checking in SearchWorker.java; /cvs/contrib/filesearch/src/org/netbeans/modules/accelerators/filesearch/SearchWorker.java,v <-- SearchWorker.java new revision: 1.2.14.5; previous revision: 1.2.14.4 done
This is great. I updated my build to the latest and greatest. However, it still has two big problems for me in Java projects and projects under CVS control: First, .class files show up - and frequently -before- the Java files. Is that something you're seeing too? I assume there are ways in NetBeans to have it filter out "generated" files using some kind of query, but if this is not used for performance reasons, can we just write in a blacklist of stuff we know we want to filter out, like .class files and backup (*~) files? Second, version control backup files (which NetBeans generates in its CVS control) are also showing up. This wold also be fixed by pruning CVS/ and .svn subdirectories. See screenshot (which I'll attach next) - notice how the .class files sort higher than the .java class - and the innerclasses sort even higher...
Created attachment 42144 [details] Screenshot showing .class files and cvs version copies in the dialog
Sorry Tor, you are saying: "I updated my build to the latest and greatest." I have to declare this statement not to be true. The sreenshot is not form the latest version. Would it be the last check box would not say "Prefer Main Project". Instead you would see "Prefer Current Project (${prj name})"
For some reason I had a version in both ide8/ and in extra/ (probably from my previous edits to cluster.properties to just build contrib/filesearch as part of my IDE - sorry about that). Better yet, the .class files are gone. However, the RevisionCache files are still there... Can anything be done about that? This is really good now - can we just get it bundled into the IDE?
I never said I fixed: 3) If you choose not to show hidden files it only works half. Means if the file or its immediate parent folder are invisible it works if some upper directory is hidden it will still show the files (I.e. works fine for the CVS folders but it may fail in other cases) It can be fixed. But is relatively complicated from the performance point of view. I will look into it. Ad putting it into distro) That's my plan. I want: a) merge it into trunk in contrib b) find some place where it should go in CVS c) start lobbying for it to become part of standard build.
2) There should be some info about searching and nothing found like in GTT Should be fixed now.
3) If you choose not to show hidden files it only works half. Means if the file or its immediate parent folder are invisible it works if some upper directory is hidden it will still show the files (I.e. works fine for the CVS folders but it may fail in other cases) Should be fixed now too.
OK, I think I'm almost done. As I already got permission from Andrei (and I hope I fixed he asked me to fix). I'm going to merge the changes into trunk of the module soon and I'll try to push it into NB standard build. Volunteers for testing welcome.
Branch bug44586_experiment_03_2007 merged into trunk of the contrib/filesearch module.
*** Issue 81999 has been marked as a duplicate of this issue. ***
Petre, could you build us the nbm ?
Please use the URL to continuous build mentioned above in the issue.
GTF is part of the standard NetBeans build now.