You are not logged in.

#1 2016-05-31 19:13:25

wander
Member
Registered: 2012-03-03
Posts: 32

FSearch - A file search application based on GTK+3

Hi,

I've been working on a new file search application for the last couple of weeks and I'd like to share my progress so far with you guys and maybe get some feedback.

FSearch is heavily inspired by an application called Everything Search Engine for Windows, that means it's focusing on performance and advanced features. Most search applications walk the filesystem on each query, which can take quite a while. To avoid that I'm building a database of all the files, similar to (m)locate, which improves the search performance a lot (less than 100ms for a normal search on 1,000,000 files). However this has a few drawbacks: You might get outdated results, since files might have been moved/removed since the last database update. To avoid that I'm planning on adding inotify support in the future (at least for certain directories) to get instant notifications on filesystem changes.

Features:

  • (almost) instant results

  • regex support

  • customizable interface

  • filter support

  • fast sort by file name, path, size, type or modification time

Screenshot: https://i.imgur.com/lerqX2G.png
Homepage: https://cboxdoerfer.github.io/fsearch/
AUR Target: https://aur.archlinux.org/packages/fsearch-git/

Hope you like it!

Offline

#2 2016-05-31 19:16:17

kokoko3k
Member
Registered: 2008-11-14
Posts: 2,390

Re: FSearch - A file search application based on GTK+3

(less than 100ms for a normal search on 1,000,000 files)

Just curious, on what cpu and query length?
On my hardware, not even mlocate is that good.

Last edited by kokoko3k (2016-05-31 19:19:32)


Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !

Offline

#3 2016-05-31 19:23:19

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

kokoko3k wrote:

Just curious, on what cpu?
On my hardware, not even mlocate is that good.

5 year old Thinkpad with an i5-2520M. The difference mostly comes from the fact that I'm using multiple threads (one per reported cpu core) to query the database.

Edit: Btw. Everything Search Engine on the same hardware running with Wine is even faster, 60-70ms vs. 70-90ms, so there's still room for improvement.

Last edited by wander (2016-05-31 19:28:50)

Offline

#4 2016-07-01 18:22:26

ninian
Member
From: United Kingdom
Registered: 2008-02-24
Posts: 726
Website

Re: FSearch - A file search application based on GTK+3

Thank you - very nice!
FSearch is already rather usable, lean and certainly speedy, achieving your aims admirably.
Particularly appreciate the regex option.

Suggestion:
Depending of what I'm doing, I might want to have several database files, say
1) for data files only - documents, pictures, etc (might have indexed ~/Documents, ~/Pictures, etc)
2) for system files - config files, desktop files, mime files (might have indexed /etc, /usr/share, /usr/local/share, etc)
3) for multimedia library - audio, video, etc (might have indexed all files stored on an external hard drive)

Simplest way would be to specify the database file (or alternative config folder?) on the command line.
But it would be really nice to have some flexibility regarding the database file(s).

Offline

#5 2016-07-01 19:38:41

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

Glad you like it. smile

Regarding more flexible database: This is already on my to-do list andl I'm probably going to implement it just like the file lists in Everything Search.
You can find a description of them here: http://www.voidtools.com/support/everything/file_lists/

Offline

#6 2016-07-01 19:47:48

ninian
Member
From: United Kingdom
Registered: 2008-02-24
Posts: 726
Website

Re: FSearch - A file search application based on GTK+3

wander wrote:

Glad you like it. smile

Regarding more flexible database: This is already on my to-do list andl I'm probably going to implement it just like the file lists in Everything Search.
You can find a description of them here: http://www.voidtools.com/support/everything/file_lists/

Super - will have a look.

Offline

#7 2016-07-01 23:16:38

ninian
Member
From: United Kingdom
Registered: 2008-02-24
Posts: 726
Website

Re: FSearch - A file search application based on GTK+3

Problem:
I find that on my netbook (1024x600 display), I cannot reduce the vertical size of the FSearch window.
So I am getting the status bar, etc chopped off.
Maximising the window still doesn't help.

Offline

#8 2016-07-02 16:02:25

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

ninian wrote:

Problem:
I find that on my netbook (1024x600 display), I cannot reduce the vertical size of the FSearch window.
So I am getting the status bar, etc chopped off.
Maximising the window still doesn't help.

Thx for reporting. Fixed on master.

Offline

#9 2016-07-02 16:34:08

ninian
Member
From: United Kingdom
Registered: 2008-02-24
Posts: 726
Website

Re: FSearch - A file search application based on GTK+3

wander wrote:

Thx for reporting. Fixed on master.

Great - thanks for fixing so fast.

Offline

#10 2016-07-24 22:16:11

Cotton
Member
From: Cornwall, UK
Registered: 2004-09-17
Posts: 568

Re: FSearch - A file search application based on GTK+3

Excellent tool.  Thanks for your contribution, it's really useful and goes some way to enhancing some of the functionality of the no longer supported Searchmonkey. The voidtool Everything definitely worth aspiring to, and something I use daily.

Some comments:
- Not sure it warrants a release version number of 0.1 alpha as it is pretty usable now and has no obvious bugs.
- Is there any chance of making the ability to search hidden folders optional?
- Does a database have to be created for each user?  And if not, do user permissions prevent files being located by other users?
- Everything allows a mixture of regex and boolean search using tags.  Is that something you're likely to implement?
- Everything is poor at sorting by date for large numbers (several thousand) of hits as it doesn't index the date field.  Fsearch doesn't appear to have this problem.
- Are you planning to add searching the content of matches found by filename?
- The addition of inotify support is very welcome, since rlocate seems to have disappeared.
- Should nothing in the search field display all files by default, similar to Everything?
- Do you have a roadmap of your plans?
- Looks like AngrySearch is already acknowledging FSearch wink

Thanks again.

Last edited by Cotton (2016-07-24 22:30:35)

Offline

#11 2016-07-25 22:04:39

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

Cotton wrote:

Excellent tool.  Thanks for your contribution, it's really useful and goes some way to enhancing some of the functionality of the no longer supported Searchmonkey. The voidtool Everything definitely worth aspiring to, and something I use daily.

Glad you like it.

- Not sure it warrants a release version number of 0.1 alpha as it is pretty usable now and has no obvious bugs.

The reason why I still label it alpha is because there might be some changes to the database or config format, which would break backwards compatibility with earlier versions. However that's not very likely, so I'm probably doing a beta release soon.

- Is there any chance of making the ability to search hidden folders optional?

That's already possible: Preferences -> Database -> Exclude -> Exclude hidden files and folders

- Does a database have to be created for each user?  And if not, do user permissions prevent files being located by other users?

Currently, yes. The reason is related to your second question - I'm not really sure how to deal with file permissions if a file isn't accessible by a certain user but it's in the database.

- Everything allows a mixture of regex and boolean search using tags.  Is that something you're likely to implement?

Yes, that's a high priority and I'm currently working on that.

- Everything is poor at sorting by date for large numbers (several thousand) of hits as it doesn't index the date field.  Fsearch doesn't appear to have this problem.

Yes, that's because FSearch indexes this data - at the cost of higher memory usage. This will be configurable in the future, so users can decide if they like faster sorting or less memory usage. But with 1.4 beta versions Everything can do that too.

- Are you planning to add searching the content of matches found by filename?

Maybe, but that's a very low priority. I'll first focus on the basic file search and if that's working good I'm going to think about searching in file contents.

- The addition of inotify support is very welcome, since rlocate seems to have disappeared.

Yes, I really hope this works well, because using inotify can be really tricky - e.g. to avoid race conditions. But that's definitely a high priority.

- Should nothing in the search field display all files by default, similar to Everything?

Yes, that's already on my todo. This will be configurable, just like in Everything.

- Do you have a roadmap of your plans?

I maintain a private todo list, but adding an official roadmap is a good idea - I will add one soon to the github page and maybe the top post here.

- Looks like AngrySearch is already acknowledging FSearch wink

Yeah, its author and I also talked a bit about both projects and he mentioned that he added a note to his project page about FSearch, seems to be a really nice guy.

Thanks again.

Np, really appreciate your feedback.

Offline

#12 2016-07-28 09:35:19

likytau
Member
Registered: 2012-09-02
Posts: 142

Re: FSearch - A file search application based on GTK+3

While I'm waiting to try this (indexing a lot of files..), I have a tiny bug report for you about the logging:

load location: /home/kau/bin
loation num entries: 1269

Missing c in 2nd 'location'

EDIT: just started using it, looks like it'll be quite useful.

One question I have is how mime handling for multiple selections is ..handled.
Consider the situation:
* you have two files foo-1.jpg and foo-2.jpg . Your search is 'foo'
* "mimeo foo-1.jpg foo-2.jpg" opens a single instance of sxiv (to be precise, by running "sxiv foo-1.jpg foo-2.jpg"). This is in accordance with the sxiv desktop file, which specifies 'sxiv %F' in the Exec line.
* Selecting both files, followed by "Open" in fsearch, instead opens two instances of sxiv, one with foo-1.jpg and one with foo-2.jpg.


Another is in a similar vein: Do you plan on adding support for sending selected results through an external program?.
This would help to effectively extend the search capabilities. (the specific use case I am thinking of is filtering based on the TMSU tags applied to files. There are other cases I have in mind too.). The critical difference here is the behaviour would not be dependent on file type -- it's a 'filter this filelist further' action, not a 'open these files' action.

Last edited by likytau (2016-07-28 09:36:19)

Offline

#13 2016-08-05 18:59:55

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

likytau wrote:

While I'm waiting to try this (indexing a lot of files..), I have a tiny bug report for you about the logging:

load location: /home/kau/bin
loation num entries: 1269

Missing c in 2nd 'location'

Thx, fixed.

One question I have is how mime handling for multiple selections is ..handled.
Consider the situation:
* you have two files foo-1.jpg and foo-2.jpg . Your search is 'foo'
* "mimeo foo-1.jpg foo-2.jpg" opens a single instance of sxiv (to be precise, by running "sxiv foo-1.jpg foo-2.jpg"). This is in accordance with the sxiv desktop file, which specifies 'sxiv %F' in the Exec line.
* Selecting both files, followed by "Open" in fsearch, instead opens two instances of sxiv, one with foo-1.jpg and one with foo-2.jpg.

Yeah, FSearch just opens each file separately. I agree, that's not very nice and I'm going to fix it.

Another is in a similar vein: Do you plan on adding support for sending selected results through an external program?.
This would help to effectively extend the search capabilities. (the specific use case I am thinking of is filtering based on the TMSU tags applied to files. There are other cases I have in mind too.). The critical difference here is the behaviour would not be dependent on file type -- it's a 'filter this filelist further' action, not a 'open these files' action.

Interesting idea. I'll add that to my to-do list, but I'm still working on some of the basic functionality (custom query syntax, custom listview widget, ...), which is more important to me, so this won't happen anytime soon.

Offline

#14 2016-08-06 08:12:58

masolit
Member
Registered: 2013-12-24
Posts: 46

Re: FSearch - A file search application based on GTK+3

.

Last edited by masolit (2019-12-03 16:07:55)

Offline

#15 2016-08-07 09:03:16

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

masolit wrote:

Please add drag and drop support! smile

Added to roadmap.

Offline

#16 2016-08-07 10:12:25

Seventh
Member
Registered: 2016-08-05
Posts: 47

Re: FSearch - A file search application based on GTK+3

This is pretty good. Added to my panel, thanks.

Offline

#17 2016-09-11 02:49:39

likytau
Member
Registered: 2012-09-02
Posts: 142

Re: FSearch - A file search application based on GTK+3

Pretty happy with this still smile I'm indexing like 1 million files and it's still quite fast

One bug report: At the beginning, it says 'updating database' in the GUI even if it is just loading. This can be misleading -- I started wondering if it wasn't finding my file because there were spaces in the filename.
IMO it would be clearer if it only said 'Updating' when it really was updating; and while it was loading, say 'Loading database'.(presumably with an icon to match)

Another bug report: "Copy" reports its keyboard shortcut as Ctrl+C, but pressing Ctrl+C does not copy; you have to use the menu (either the context menu or Edit->Copy works). IMO the most likely cause is that the context (right-click) menu does specify Ctrl+C, but the Edit menu does not (which implies they are actually different actions; this is usually not what you want).
This is more serious than the other bug, for me -- I want to copy stuff all the time.

Last edited by likytau (2016-09-11 02:52:27)

Offline

#18 2016-09-27 08:10:06

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

likytau wrote:

Pretty happy with this still smile I'm indexing like 1 million files and it's still quite fast

One bug report: At the beginning, it says 'updating database' in the GUI even if it is just loading. This can be misleading -- I started wondering if it wasn't finding my file because there were spaces in the filename.
IMO it would be clearer if it only said 'Updating' when it really was updating; and while it was loading, say 'Loading database'.(presumably with an icon to match)

Yes sure, will be fixed.

Another bug report: "Copy" reports its keyboard shortcut as Ctrl+C, but pressing Ctrl+C does not copy; you have to use the menu (either the context menu or Edit->Copy works). IMO the most likely cause is that the context (right-click) menu does specify Ctrl+C, but the Edit menu does not (which implies they are actually different actions; this is usually not what you want).
This is more serious than the other bug, for me -- I want to copy stuff all the time.

Indeed, that's weird it worked at one point. But thanks, I'll look into fixing it right away.

Edit: Fixed the missing copy keyboard shortcut.

Last edited by wander (2016-09-27 08:22:01)

Offline

#19 2016-11-01 06:22:00

atrotors
Member
Registered: 2015-07-20
Posts: 9

Re: FSearch - A file search application based on GTK+3

Just here to thank you
All of the gui applications to find files are really stupid for some reason and you saved me a lot of headache, thanks!
Like if the file has "fit1049" in the name, searching "1049" doesn't have any results. Also "fit2003fit1049" (typo) in the name doesn't yield any results unless you search the entire word. But yours works great and runs really fast too (I don't have that many files)
Thanks a lot!

Last edited by atrotors (2016-11-01 06:23:04)

Offline

#20 2016-11-02 18:32:38

wander
Member
Registered: 2012-03-03
Posts: 32

Re: FSearch - A file search application based on GTK+3

atrotors wrote:

Just here to thank you
[...]
Thanks a lot!

I'm glad you like it smile

Offline

Board footer

Powered by FluxBB