even in not unlikely situations.
* GrepWindow::_SelectFilesInTracker() was still leaking entry_refs in the
success code path.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27577 a95241bf-73f2-0310-859d-f6bbb57e9c96
* In the ChangesIterator, just remove removed files from the HashMap, regardless
if they could be considered "temporary" or not.
* If a file is removed, we can directly remove it from the results list. This
makes removing files from the result list more robust and quicker if this
was the only thing that happened with regards to node monitoring (the grep
process does not need to be run again).
* Refactored removing result items from the list on result notifications.
* Beginnings of supporting moving files within the watched folder hierarchy.
If they were just moved, the new location should update in the list.
(not well tested)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27377 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Mention the fact that the same code is used in DiskUsage.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27375 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Decreased the node monitor activity timeout to 150 ms
* _StartNodeMonitoring() simply starts watching the root folder with the
B_WATCH_RECURSIVELY flag set. (Requires forthcomming changes to
BPathMonitor, but it was broken anyways.)
* _StopNodeMonitoring() returns early if node monitoring is inactive.
* When node monitoring is started after a search finished, it is done
asynchronous, since messing with the other controls results in modification
messages that otherwise stop node monitoring again. Now the message is
inserted last and works reliably.
* When receiving B_PATH_MONITOR messages, they are supposed to simply contain
a "path" field with the full path to the node that changed. That's not
currently the case with BPathMonitor, but I will commit that stuff next.
(Was broken before anyways.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26935 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added better tracing support.
* GetNextName() was not incrementing the index when iterating to the next entry
and was therefor broken if the object managed more than one entry.
* Made a small simplification in EntryRemoved().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26934 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Output something if the node monitor message does not contain the expected
fields (Haiku node monitoring is soo much easier...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26869 a95241bf-73f2-0310-859d-f6bbb57e9c96
* On Haiku, this will make them disappear from the results list.
* On BeOS, it will only work around the problem that we don't know
which file was removed from the node monitoring message...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26848 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the current search. If new files match the pattern, the appear in the
results, or are removed if they don't match anymore. The results also
adapt to changes in the files.
Basically, I added another iterator that is also used to track changes when
node monitor events arrive. Only those changed files are grepped again after
a timeout of .5 seconds when no new node monitor events pour in.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26809 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Beginnings of node monitoring support. Currently disabled, but detects
new, changed and removed files. Folders untested yet. There may also be
a problem with the toplevel folders when a pose selection message is used.
That's untested too as of yet.
* Removed some superfluous whitespace.
* Small refactoring in FolderIterator to access some stuff from the outside
as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26795 a95241bf-73f2-0310-859d-f6bbb57e9c96
object.
* Improved check that enforces search pattern history limit to also handle
the case when the limit is changed in the source.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26787 a95241bf-73f2-0310-859d-f6bbb57e9c96
* FileIterator is now a mostly abstract interface
* FolderIterator is the currently only implementation (there could be
MessageIterator for an even better separation, which would read the top
level search folders from the BMessage with the selected poses, but it
would mostly use the same code for traversing the subfolders anyways so I
left that for the time being.)
* The Grepper and FolderIterator now copy the current settings from the Model
at instantiation. Since they run in a separate thread and the Model may
actually be changed from the Window thread, I think this is just a cleaner
and more safe solution.
* Cleanup here and there.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26786 a95241bf-73f2-0310-859d-f6bbb57e9c96
node monitoring easier. Also, FileIterator will be split to make the code
cleaner with regards to folder or selection mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26752 a95241bf-73f2-0310-859d-f6bbb57e9c96
