Hi,

With the option Update database on start enabled, it's a very time-consuming job for databse updating each time after fsearch is started. It seems that the update operation is not incremental. I want to know whether this operation can be further sped up / optimized?

Regards, HY

Describe the bug It is not possible to resize the width of any columns, nor move the column order regardless of the size of the FSearch window.

Expected behavior I would expect to be able to:

• resize the columns in order to view the values without having to hover over an item (tooltip works well)
• move the left to right order of the columns to suit my preference

Desktop (please complete the following information):

• OS: Linux Mint 20.3 Cinnamon
• Cinnamon Version 5.2.7
• Kernal 5.4.0.1.100-generic
• How you installed FSearch: PPA
• Version 0.1.2
• Output of localectl status System Locale: LANG=en_US.UTF-8 VC Keymap: n/a X11 Layout: us X11 Model: pc105

OS: DebianBuster Installed: Followed the build-instructions on github Version: FSearch 0.3.alpha0 localectl status: System Locale: LANG=de_DE.UTF-8 VC Keymap: n/a X11 Layout: de X11 Model: pc105

Problem:

a) when i try to 'open directory' at a found file: -> 'Error when getting information for content type 'inode/directory": Keine Standardanwendung bekannt.'

b) when i try to open the found file (doubleclick or ENTER: -> 'Error when getting Information for content type "application/x-7z-compressed": keine Standardanwendung bekannt' (7z is just an example, happens also with other filetypes)

This happens only on one of my machines, running debian buster. When i checked fsearch 0.1 on that computer (just happend to be at hand on that machine): both options work perfect.

On another PC running debian buster fsearch0.3alpha works without problems also.

So the problem only occurs on one machine and only with fsearch 0.3 alpha.

(temporary) solution: using fsearch0.1

I speak about this dialog field:

Here normally I have "/" as search folder. But sometimes I want to change my search folder for a particular search and replace "/" through another folder. But later I want to go back to "/".

So for example I want to look after the greatest files in the folder ~/.thunderbird/oabbl9j2.default/Mail So I go to and replace "/" through "~/.thunderbird/oabbl9j2.default/Mail". Then I search for all files and sort the result after the file size. This way I see, which are the biggest files in this folder. Then I have to go back into... ... To delete the folder "~/.thunderbird/oabbl9j2.default/Mail" and add again "/".

So what is my feature request? Please add the possibility to deactivate search folders.

So in the scenario above I just could deactivate "/" temporary, add "~/.thunderbird/oabbl9j2.default/Mail". Later I just could again activate "/" and delete "~/.thunderbird/oabbl9j2.default/Mail".

Describe the bug When attempting to build fsearch 0.1 under MacPorts I get several errors in fsearch_database.c.

1. There is no such thing as #include <malloc.h> under macOS, I use #include <stdlib.h> instead.
2. There is no such thing as 'strverscmp' on *NIX platforms other than linux.
3. There is no such thing as 'AT_NO_AUTOMOUNT' on *NIX platforms other than linux.

To Reproduce Steps to reproduce the behavior: When building

Expected behavior Successful build (as for previous tag 0.1beta4)

Screenshots

1. w/o malloc patch fsearch_database.c:28:10: fatal error: 'malloc.h' file not found #include <malloc.h> ^~~~~~~~~~ CC fsearch-fsearch_database_view.o

2. with malloc and AT_NO_AUTOMOUNT patch

--- src/fsearch_database.c.orig	2021-09-24 11:41:49.000000000 -0500
+++ src/fsearch_database.c	2021-09-28 07:30:47.000000000 -0500
@@ -25,7 +25,7 @@
 #include <fcntl.h>
 #include <fnmatch.h>
 #include <glib/gi18n.h>
-#include <malloc.h>
+#include <stdlib.h>
 #include <stdbool.h>
 #include <stdio.h>
 #include <string.h>
@@ -1262,7 +1262,7 @@
         g_string_append(path, dent->d_name);
 
         struct stat st;
-        if (fstatat(dir_fd, dent->d_name, &st, AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT)) {
+        if (fstatat(dir_fd, dent->d_name, &st, AT_SYMLINK_NOFOLLOW)) {
             g_debug("[db_scan] can't stat: %s", path->str);
             continue;
         }

Undefined symbols for architecture x86_64: "_malloc_trim", referenced from: _db_free in fsearch-fsearch_database.o "_strverscmp", referenced from: _db_entry_compare_entries_by_path in fsearch-fsearch_database_entry.o _sort_entry_by_path_recursive in fsearch-fsearch_database_entry.o _db_entry_compare_entries_by_name in fsearch-fsearch_database_entry.o _db_entry_compare_entries_by_extension in fsearch-fsearch_database_entry.o

Desktop (please complete the following information):

• macOS 10.14.6
• build using MacPorts Portfile, see https://github.com/macports/macports-ports/blob/master/sysutils/fsearch/Portfile
• Version 0.1
• Output of localectl status: non-existent under macOS

Additional context Notes:

1. _malloc_trim is not portable, see http://www.hep.by/gnu/gnulib/malloc_005ftrim.html
2. strverscmp is not portable, see https://www.gnu.org/software/gnulib/manual/html_node/strverscmp.html

PS: There is an issue with configure.ac

AX_CHECK_COMPILE_FLAG([-std=c11], [CFLAGS+=" -std=c11" ],
                      [echo "C compiler cannot compile C11 code. Abort"
                       exit -1
                      ])

even though I have configured the Portfile to use compiler.cxx_standard 2011

(fsearch:4069): GLib-CRITICAL **: 22:48:06.999: g_utf8_strdown: assertion 'str != NULL' failed Segmentation fault

The error began to appear after one of the updates, everything worked before. I can still search using Latin characters, but when I enter Cyrillic, it crashes.

Elementary OS 5.1.7 Linux 5.4.0-52-lowlatency

The bug persists on the latest version.

I tried my hands on implementing issue #84

At the moment it closes the application after opening the file (or the folder of the file) via the keyboard.

But it doesn't work when you open it via the mouse (double-clicking on it). Someone can argue if this should be the case or not. Personally I would want it to stay open when using the mouse because then I'm looking for something in the file and maybe opening another file after that.

Another point would be if the application should close or minimize into the taskbar?

Describe the bug after updating to the june 8th daily build, everytime I start up the program, it would get stuck updating/scanning the folders.

Expected behavior I am not sure what version I was on before upgrading to the June 8th daily build, but everything worked fine before the upgrade

Screenshots

Desktop (please complete the following information):

• OS: [Linux Mint 20]
• How you installed FSearch [PPA]
• Version [FSearch 0.1beta4, june 8th daily build]
• Output of localectl status
  System Locale: LANG=en_US.UTF-8 VC Keymap: n/a X11 Layout: us X11 Model: pc105

Additional context Add any other context about the problem here.

Nothing is added to database if root directory / is included.

I'd like to add just / and then specifically exclude directories and files. This doesn't seem to work though...

Hi Developer, FSearch is a mandotary tool for me but updating database every start is annoying. Is it possible to have a feature like this: "Update database if not updated in one week"

Thanks

Describe the bug FSearch supports the possibility for double clicking on a folder and then thunar opens with the content of that folder. -> When I use this function I have a "busy mouse pointer" for about half a minute. When I remember correctly: This was not an issue with FSearch 0.1

To Reproduce Gif-Animaion:

Expected behavior The mouse pointer is busy for about half a second or less.

Desktop (please complete the following information):

• OS:MX-Linux 19.4 Xfce (Debian 10 based)
• How you installed FSearch MX package installer
• Version 0.2.2
• Output of localectl status: System has not been booted with systemd as init system (PID 1). Can't operate. Failed to create bus connection: Der Rechner ist nicht aktiv

Describe the bug Folders are not opening from context menu in FSearch.

To Reproduce Steps to reproduce the behavior:

1. Run fsearch
2. Select a file/folder in main window
3. Right-click > Open Folder (or Ctrl+Return)

Expected behavior Folder should open in file manager window (I'm using use thunar 4.18.1)

Screenshots

Desktop (please complete the following information):

• OS: EndeavourOS (Xfce 4.18.0)
• How you installed FSearch: AUR
• Version: FSearch 0.2.2 (AUR-stable)
• Output of localectl status:

System Locale: LANG=en_US.UTF-8
   VC Keymap: us
  X11 Layout: u

Additional context Terminal output:

ERR<45376>: ../src/bin/tools/filemanager/e_fm_cmdline.c:53 fm_open_reply() org.freedesktop.DBus.Error.ServiceUnknown: The name org.enlightenment.FileManager was not provided by any .service files
## Copy & Paste the below (until EOF) into a terminal, then hit Enter

eina_btlog << EOF
/usr/lib/libeina.so.1 0x6d469b307324 0x6d469b2dc000
/usr/lib/libeina.so.1 0x6d469b2fe861 0x6d469b2dc000
/usr/lib/libeina.so.1 0x6d469b30b329 0x6d469b2dc000
/usr/bin/enlightenment_filemanager 0x55a738a53ab 0x55a738a3000
/usr/lib/libeldbus.so.1 0x6d469b214ac9 0x6d469b206000
/usr/lib/libdbus-1.so.3 0x6d469ad13bc0 0x6d469acff000
/usr/lib/libdbus-1.so.3 0x6d469ad18120 0x6d469acff000
/usr/lib/libeldbus.so.1 0x6d469b21ad4a 0x6d469b206000
/usr/lib/libecore.so.1 0x6d469b267e63 0x6d469b252000
/usr/lib/libeo.so.1 0x6d469aea2750 0x6d469ae8e000
/usr/lib/libeo.so.1 0x6d469aea3e77 0x6d469ae8e000
/usr/lib/libecore.so.1 0x6d469b2708c0 0x6d469b252000
/usr/lib/libecore.so.1 0x6d469b270f9d 0x6d469b252000
/usr/lib/libecore.so.1 0x6d469b27ade9 0x6d469b252000
/usr/lib/libecore.so.1 0x6d469b274807 0x6d469b252000
/usr/lib/libecore.so.1 0x6d469b26ce28 0x6d469b252000
/usr/bin/enlightenment_filemanager 0x55a738a5127 0x55a738a3000
/usr/lib/libc.so.6 0x6d469b013290 0x6d469aff0000
/usr/lib/libc.so.6 0x6d469b01334a 0x6d469aff0000
/usr/bin/enlightenment_filemanager 0x55a738a5205 0x55a738a3000
EOF

Did you unload the EFM module? Try loading it.

Describe the bug in started to happen after some recent os update. while opening a folder, fsearch opens a duplicate session of a dolphin file manager instead of opening a folder in the new tab of the existing dolphin session.

To Reproduce

1. open dolphin fm with few tabs
2. open fsearch
3. search for any folder
4. double click on it

Expected behavior fsearch should open existing dolphin session and create there a new tab with desired folder

Screenshots https://i.imgur.com/vviGNIK.mp4

Desktop (please complete the following information):

• OS: manjaro plasma

• How you installed FSearch aur, fsearch-git

• Version [output of fsearch --version] FSearch 0.3.alpha0 (AUR-devel) tested on aur stable also

• Output of localectl status System Locale: LANG=en_US.UTF-8 LC_NUMERIC=ru_RU.UTF-8 LC_TIME=ru_RU.UTF-8 LC_MONETARY=ru_RU.UTF-8 LC_PAPER=ru_RU.UTF-8 LC_NAME=ru_RU.UTF-8 LC_ADDRESS=ru_RU.UTF-8 LC_TELEPHONE=ru_RU.UTF-8 LC_MEASUREMENT=ru_RU.UTF-8 LC_IDENTIFICATION=ru_RU.UTF-8 VC Keymap: us X11 Layout: us

Additional context

If opened, closed with Escape, and opened again, FSearch may open underneath other windows instead of on top of everything.

To Reproduce

1. Bind fsearch to a keyboard shortcut (On Gnome in Ubuntu 22.04, I bound it to Ctrl+Alt+O in settings)
2. Enable "close FSearch on Escape" setting
3. Open some other windows
4. Open FSearch, then press Escape
5. Open FSearch, observe it appears behind other windows

If for step 4 you press alt+f4 or click the X button, FSearch correctly appears on top of everything in step 5.

Desktop (please complete the following information):

• OS: Ubuntu 22.04
• Ubuntu PPA version
• Version: kFSearch 0.2.2 (PPA-stable)
• Output of localectl status

   System Locale: LANG=en_US.UTF-8
       VC Keymap: n/a
      X11 Layout: us
       X11 Model: pc105

Is your feature request related to a problem? Please describe. Sometimes I look for a conf file that lies on the root partition in Linux and I want to edit it. It would be user friendly, if we were able to right click on the search result of FSearch and have the entry "edit with root rights with for example Featherpad".

Describe alternatives you've considered Until now I use right click "open folder". Thunar opens. In thunar I look again for the file and choose in thunar "edit as root". Which is a bit cumbersome.

Maybe you can add an option in "settings", so that users, who are afraid of destroying their system by such a possibility, can deselect this possibility. Or it may be by default inactivated, but can be activated in settings.

What do you think?

I have a lot of soft symlinks of various files in my folders, so that they can be found from various places while browsing with Nautilus.

However, they all show up as identical search results in FSearch. There should be some visual distinction to tell them apart from the original, "real" file that the symlinks are pointing.

Nautilus simply shows an arrow emblem, as you can see in the upper half of this screenshot (in this particular case, it also shows the read-only permission indicator emblem):

The lower half is how fsearch currently represents the same results.

Another potential (perhaps simpler to implement) approach would be to make the row 50% opaque (or maybe up to 70% opaque) to denote that it is a secondary result to the original.

Nowadays there is a standardized way for your app to authoritatively know (without just trying to "guess" whether the current GTK theme is dark or not) what the user's intent is in terms of light/dark themes.

• Overview here: https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/
• Implementation tips here: https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference

Most applications already support this with GNOME 42+ and Elementary OS 6, even non-purely-GTK applications such as Firefox. I believe lots of applications on KDE support this standard as well.

Knowing "what the user actually wishes for" lets your app switch between the two styles in realtime with a clear standardized signal, and if also lets it confidently ship its own harmonized colors/stylesheet for both light/dark scenarios if needed.

Text-heavy apps can let the user decide if they want the app to remain light (or dark) at all times or if they want it to follow/inherit the light vs dark status from the OS. Simple apps that don't have fancy stylesheets (unlike source code text editors) can simply offer the choice between: "Follow system's preference", "Always light", or "Always dark".

An example of a commonly used UI for this in GTK and GNOME apps is the screenshot you can see here: https://github.com/mjakeman/extension-manager/issues/218

Or, if you want to simplify your codebase by reducing settings, you may choose to have the app only follow the system dark/light preference at all times.