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.

Bug 44586 - Add a way to quickly locate and open a file via the keyboard
Summary: Add a way to quickly locate and open a file via the keyboard
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Petr Hrebejk
URL:
Keywords:
: 41967 81999 99496 (view as bug list)
Depends on: 95974
Blocks:
  Show dependency tree
 
Reported: 2004-06-08 18:23 UTC by David-john Burrowes
Modified: 2007-05-22 17:33 UTC (History)
16 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
eclipse GTT and GTF (48.84 KB, image/png)
2007-03-14 00:10 UTC, Pavel Buzek
Details
Screenshot showing .class files and cvs version copies in the dialog (169.40 KB, image/png)
2007-05-04 16:21 UTC, Torbjorn Norbye
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David-john Burrowes 2004-06-08 18:23:28 UTC
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.
Comment 1 Jesse Glick 2004-06-08 18:45:15 UTC
There is already the Alt-Shift-O (Fast Open) feature to open classes
quickly.
Comment 2 David-john Burrowes 2004-06-08 19:03:18 UTC
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.

Comment 3 Petr Hrebejk 2004-06-09 12:43:25 UTC
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
Comment 4 jrojcek 2004-06-09 20:59:31 UTC
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).
Comment 5 Roman Strobl 2005-01-21 12:20:09 UTC
Obsolete target milestone, changed to TBD. Please re-evaluate.
Comment 6 Jesse Glick 2005-05-10 14:12:30 UTC
*** Issue 41967 has been marked as a duplicate of this issue. ***
Comment 7 Martin Krauskopf 2007-03-09 09:07:15 UTC
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 :)
Comment 8 Andrei Badea 2007-03-09 09:32:52 UTC
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).
Comment 9 headius 2007-03-09 21:39:01 UTC
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.
Comment 10 Pavel Buzek 2007-03-10 05:27:46 UTC
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.
Comment 11 Petr Hrebejk 2007-03-11 16:07:28 UTC
Hmm, can someone tell me what this issues has to do with editor? Please.
Comment 12 Petr Hrebejk 2007-03-11 16:09:31 UTC
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.

Comment 13 headius 2007-03-11 19:01:13 UTC
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.
Comment 14 Petr Hrebejk 2007-03-12 02:39:05 UTC
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 

Comment 15 Pavel Buzek 2007-03-12 06:27:48 UTC
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
Comment 16 headius 2007-03-12 06:54:19 UTC
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.
Comment 17 Andrei Badea 2007-03-12 11:48:07 UTC
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).
Comment 18 Petr Hrebejk 2007-03-12 12:35:26 UTC
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

Comment 19 Petr Hrebejk 2007-03-12 12:38:25 UTC
For record: Issues by Andrei. 

10) GTF does not work well when regexp characters are used in the searched text.
11) VisibilityQuery
Comment 20 Jesse Glick 2007-03-12 15:19:25 UTC
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.
Comment 21 headius 2007-03-12 15:44:47 UTC
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.
Comment 22 Andrei Badea 2007-03-12 15:47:35 UTC
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
Comment 23 Pavel Buzek 2007-03-12 19:00:07 UTC
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.
Comment 24 Petr Hrebejk 2007-03-12 21:14:30 UTC
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. 
Comment 25 Jesse Glick 2007-03-12 21:21:04 UTC
Test and Generate Javadoc actions are sensitive to the selected project and
ignore the main project. The main project concept should be used sparingly.
Comment 26 Torbjorn Norbye 2007-03-12 21:30:44 UTC
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.
Comment 27 Andrei Badea 2007-03-12 22:32:00 UTC
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.
Comment 28 Petr Hrebejk 2007-03-12 22:53:13 UTC
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 :-)
Comment 29 Torbjorn Norbye 2007-03-12 23:17:52 UTC
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.
Comment 30 Petr Hrebejk 2007-03-13 00:29:21 UTC
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.

Comment 31 Torbjorn Norbye 2007-03-13 00:38:44 UTC
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.
Comment 32 Martin Krauskopf 2007-03-13 00:50:01 UTC
> 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.
Comment 33 Petr Hrebejk 2007-03-13 01:20:01 UTC
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?
Comment 34 Petr Hrebejk 2007-03-13 01:22:09 UTC
And stop throwing bad UI ideas on me if you want to have at least some
implementation. :-)
Comment 35 Martin Krauskopf 2007-03-13 01:29:05 UTC
> 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 :)
Comment 36 headius 2007-03-13 04:04:49 UTC
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.
Comment 37 Torbjorn Norbye 2007-03-13 04:17:07 UTC
"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.
Comment 38 Petr Hrebejk 2007-03-13 11:17:43 UTC
"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? 
Comment 39 headius 2007-03-13 20:29:41 UTC
>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.
Comment 40 Pavel Buzek 2007-03-14 00:10:39 UTC
Created attachment 39460 [details]
eclipse GTT and GTF
Comment 41 Vitezslav Stejskal 2007-04-03 23:17:16 UTC
*** Issue 99496 has been marked as a duplicate of this issue. ***
Comment 42 headius 2007-04-04 22:27:47 UTC
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.
Comment 43 Torbjorn Norbye 2007-04-04 22:34:19 UTC
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).
Comment 44 headius 2007-04-11 17:49:49 UTC
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.
Comment 45 Petr Hrebejk 2007-04-12 09:48:55 UTC
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.
Comment 46 Andrei Badea 2007-04-12 14:01:17 UTC
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.
Comment 47 Erno Mononen 2007-04-13 11:57:23 UTC
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).
Comment 48 hbjastad 2007-04-13 12:14:22 UTC
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...
Comment 49 headius 2007-04-20 23:55:44 UTC
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?
Comment 50 Petr Hrebejk 2007-04-23 18:40:17 UTC
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/



Comment 51 headius 2007-04-23 23:09:49 UTC
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.
Comment 52 Michel Graciano 2007-04-24 04:58:27 UTC
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?
Comment 53 Petr Hrebejk 2007-04-24 09:47:39 UTC
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.
Comment 54 Andrei Badea 2007-04-24 09:52:39 UTC
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.
Comment 55 Petr Hrebejk 2007-04-24 10:10:32 UTC
Are you still againt merging the branch into trunk of the module? Why? I did
everything you asked for.
Comment 56 Andrei Badea 2007-04-24 12:45:56 UTC
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.
Comment 57 Petr Hrebejk 2007-04-24 13:34:49 UTC
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). 
Comment 58 Andrei Badea 2007-04-24 18:09:54 UTC
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.
Comment 59 Jesse Glick 2007-04-24 18:27:08 UTC
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.
Comment 60 jrojcek 2007-04-25 13:01:22 UTC
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.
Comment 61 Petr Hrebejk 2007-04-25 14:11:48 UTC
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.  
Comment 62 headius 2007-04-25 20:20:11 UTC
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.
Comment 63 jrojcek 2007-04-26 08:17:14 UTC
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.
Comment 64 Petr Hrebejk 2007-04-26 08:57:52 UTC
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.
Comment 65 headius 2007-04-26 09:25:27 UTC
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.
Comment 66 Petr Hrebejk 2007-05-04 13:54:07 UTC
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
Comment 67 Petr Hrebejk 2007-05-04 14:23:52 UTC
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

Comment 68 Torbjorn Norbye 2007-05-04 16:20:21 UTC
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...

Comment 69 Torbjorn Norbye 2007-05-04 16:21:22 UTC
Created attachment 42144 [details]
Screenshot showing .class files and cvs version copies in the dialog
Comment 70 Petr Hrebejk 2007-05-04 17:59:40 UTC
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})"
Comment 71 Torbjorn Norbye 2007-05-04 18:53:39 UTC
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?
Comment 72 Petr Hrebejk 2007-05-04 19:08:47 UTC
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.

Comment 73 Petr Hrebejk 2007-05-05 13:41:45 UTC
2) There should be some info about searching and nothing found like in GTT

Should be fixed now.
Comment 74 Petr Hrebejk 2007-05-05 16:13:31 UTC
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.
Comment 75 Petr Hrebejk 2007-05-05 17:10:30 UTC
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.
Comment 76 Petr Hrebejk 2007-05-05 20:53:04 UTC
Branch bug44586_experiment_03_2007 merged into trunk of the contrib/filesearch
module.
Comment 77 Petr Hrebejk 2007-05-05 21:12:11 UTC
*** Issue 81999 has been marked as a duplicate of this issue. ***
Comment 78 Marian Mirilovic 2007-05-13 23:36:26 UTC
Petre,
could you build us the nbm ?
Comment 79 Petr Hrebejk 2007-05-14 09:08:29 UTC
Please use the URL to continuous build mentioned above in the issue.
Comment 80 Petr Hrebejk 2007-05-22 17:33:20 UTC
GTF is part of the standard NetBeans build now.