Settings that could be simplified (automated), deduplicated, or with different defaults

[nekohayo]

Here are a few observations and suggestions "settings in the UI that don't really need to exist", to simplify your code paths and testing matrix (in line with this long-standing philosophy article that shaped GNOME2, GNOME3, and newer).

• "Remember window size": there is not a single usecase where users don't want window sizes to be remembered. Otherwise you're just creating "shit work" or creating meaningless choices for your users. This particular setting, I can say without hesitation: remove the setting and make that the default behavior.
• "Exit on Escape": that's dangerous; let the user use standard WM shortcuts for this (Alt+F4, Ctrl+Q, Ctrl+W, etc.) as per issue #392. Esc should instead clear the search entry (and focus the caret into the newly blank search entry).
• "Show highlighted search terms": again there's no reason for users not to want this to be enabled. Enable it by default and get rid of the setting checkbox.
• "Show tooltips": same thing. Enable by default, and remove the checkbox.
• "Remember column configuration" and "Remember sort order": again something that should be enabled by default and automatic for users. There's no reason not to remember the application's state and to create extra work for users each time.
• "Single click to open": if there is no action that distinguishes between single and double click, just make that the default, double click does not need to exist and it just is a terrible pattern to avoid if we can, because people like my dad and aunts don't understand the abstract notion of double click at all (especially when to use it or not), and it requires fine hand motor coordination (my aunt can't double click properly).
• "Show warning dialogs when file/folder failed to open": just show the dialogs. There is no reason not to show them, ever. Don't put an option for this here, it's meaningless.
• "Show database indexing status": why wouldn't you show this in the statusbar when the statusbar is present? Again, remove this if there's no reason for it to be turned off.

As you can see, I'm just getting rid of the meaningless cruft. The rest of the settings, especially those that affect performance or the scope of the search, are respectfully left in place.

There are some settings I find questionable ("Behavior after successfully opening a file" and "Launch desktop files" or "Use binary units instead of decimal units", for example; particularly since the former seems mostly like a workaround for broken window managers that are not properly handling focus stealing prevention for utility windows like the flatpak portal prompt) but I suspect suggesting their removal could be controversial.

A side-effect of removing the cruft is that what remains that truly matters is more easily found, and/or easier to lay out in a well-organized manner in the GUI.

[JohnFitz]

Just throwing my two cents in. I agree with you on almost all of what you point out, and even wondered what the use cases are for many of the settings myself.

I disagree however that the "Single click to open" setting should be removed. I mostly use FSearch to manage and organise files. Selecting multiple files from a result set, so that I can copy, cut or delete them, is more cumbersome when the Single click behaviour is turned on. I'd also contend that most major desktop OS file managers are pretty consistent that "double clicking = open" and "single click = select" but the option is there if it's needed as in your examples.

That's my long-winded way of saying, that the defaults should be changed if it helps, just don't remove that particular option entirely please! :pleading_face:

(I also quite like the "Behavior after successfully opening a file" feature but it personally wouldn't personally bother me as much if it went away)

"Show warning dialogs when file/folder failed to open": just show the dialogs. There is no reason not to show them, ever. Don't put an option for this here, it's meaningless.

Funnily, every time the user deletes a file, there's another warning dialog stating that the database needs to be updated for FSearch to become aware of the change. I must have seen it a hundred times. I'd love to have an option to turn that one off :grinning:, or just have it once per session. But since Christian seems to be currently working on live updates, it probably won't be around too much longer.

[nekohayo]

Selecting multiple files from a result set, so that I can copy, cut or delete them, is more cumbersome when the Single click behaviour is turned on.

Hmm, but can't you do the Ctrl+Click (and right click, and shit+click) selections all the same? Though I guess if you mainly use shift-clicking, there's some bug happening there if there was no existing selection before initiating the first shift-click, so I can understand how that would be annoying, though perhaps it would be best to just address that bug instead?

every time the user deletes a file, there's another warning dialog stating that the database needs to be updated for FSearch to become aware of the change. I must have seen it a hundred times. I'd love to have an option to turn that one off

That's another meaningless user dialog in my view, very much reminiscent of Joel Spolsky's article above ("Choices"). If the app needs to update the DB, just do it, remove the relevant entry from the DB in the background (or if it's too expensive, queue all the deletions to happen in batch upon exit or after a while on idle) and don't bother the user with that, don't add an option to highlight broken behavior...

[cboxdoerfer]

Here are a few observations and suggestions "settings in the UI that don't really need to exist", to simplify your code paths and testing matrix (in line with this long-standing philosophy article that shaped GNOME2, GNOME3, and newer).

Thx!

• "Remember window size": there is not a single usecase where users don't want window sizes to be remembered. Otherwise you're just creating "shit work" or creating meaningless choices for your users. This particular setting, I can say without hesitation: remove the setting and make that the default behavior.

I agree.

• "Exit on Escape": that's dangerous; let the user use standard WM shortcuts for this (Alt+F4, Ctrl+Q, Ctrl+W, etc.) as per issue [BUG] Use standard keyboard shortcuts for clearing the search, minimizing the window, or activating the hamburger menu #392. Esc should instead clear the search entry (and focus the caret into the newly blank search entry).

I think an argument can be made for having support for "Exit on ESC", because that's how many launchers and search utilities (GNOME Shell, uLauncher, Albert, KRunner, rofi, ...) behave.

Having Esc clear the search entry is a behavior I don't think I've seen before in other applications and it's also not something I would expect to happen.

• "Show highlighted search terms": again there's no reason for users not to want this to be enabled. Enable it by default and get rid of the setting checkbox.

I agree.

• "Show tooltips": same thing. Enable by default, and remove the checkbox.

I agree.

• "Remember column configuration" and "Remember sort order": again something that should be enabled by default and automatic for users. There's no reason not to remember the application's state and to create extra work for users each time.

I agree.

• "Single click to open": if there is no action that distinguishes between single and double click, just make that the default, double click does not need to exist and it just is a terrible pattern to avoid if we can, because people like my dad and aunts don't understand the abstract notion of double click at all (especially when to use it or not), and it requires fine hand motor coordination (my aunt can't double click properly).

I don't agree. I'm not a fan of single click at all, so having that as the only option is definitely not something I want to have. But I know that there people out there who prefer to use single click and many projects offer support for that (KDE, Nautilus, Thunar, ...), so I don't want to remove that option.

• "Show warning dialogs when file/folder failed to open": just show the dialogs. There is no reason not to show them, ever. Don't put an option for this here, it's meaningless.

I agree.

• "Show database indexing status": why wouldn't you show this in the statusbar when the statusbar is present? Again, remove this if there's no reason for it to be turned off.

I agree.

As you can see, I'm just getting rid of the meaningless cruft. The rest of the settings, especially those that affect performance or the scope of the search, are respectfully left in place.

There are some settings I find questionable ("Behavior after successfully opening a file" and "Launch desktop files" or "Use binary units instead of decimal units", for example; particularly since the former seems mostly like a workaround for broken window managers that are not properly handling focus stealing prevention for utility windows like the flatpak portal prompt) but I suspect suggesting their removal could be controversial.

"Behavior after successfully opening a file": This is meant for the use case where FSearch is only used as a one-shot application: "Open one file and then its job is done".

[cboxdoerfer]

Though I guess if you mainly use shift-clicking, there's some bug happening there if there was no existing selection before initiating the first shift-click, so I can understand how that would be annoying, though perhaps it would be best to just address that bug instead?

Can you describe the bug? It behaves as expected on my machine.

[cboxdoerfer]

Funnily, every time the user deletes a file, there's another warning dialog stating that the database needs to be updated for FSearch to become aware of the change. I must have seen it a hundred times. I'd love to have an option to turn that one off grinning, or just have it once per session. But since Christian seems to be currently working on live updates, it probably won't be around too much longer.

Yes, this dialog is only used as workaround until the live updates are ready. Because without the dialog I often got mails from users who thought that deletion didn't work, because the search results wouldn't update.

[cboxdoerfer]

If the app needs to update the DB, just do it, remove the relevant entry from the DB in the background (or if it's too expensive, queue all the deletions to happen in batch upon exit or after a while on idle) and don't bother the user with that, don't add an option to highlight broken behavior...

That's the ultimate goal — to just update the database to make it obvious that the file was deleted — and planned for the 0.3 release, but until that is implemented I needed a quick way to give users feedback that the deletion was successful, even when the search results didn't reflect that.

[nekohayo]

I think an argument can be made for having support for "Exit on ESC", because that's how many launchers and search utilities (GNOME Shell, uLauncher, Albert, KRunner, rofi, ...) behave.

For the record, what I'm describing is how GNOME Shell behaves (I haven't tested the others¹ though). If you press Esc after typing something in the search field, it clears the search field, it doesn't immediately exit the overview mode. The only reason why a 2nd Esc press then exits the overview mode when the search field is already blank, is that it doesn't make sense to use Alt+F4 or Ctrl+Q or Ctrl+W on a window manager, because it's not a window and it's not a process that you are meant to stop running; GNOME Shell is much more like a panel applet, functionally speaking.

As for other applications that follow the same principle: Nautilus, DevHelp, Yelp, GTG, GNote, Gedit, Builder, Epiphany, Firefox, LibreOffice, Shortwave, etc. all clear the search on Esc (and since search is not their sole purpose, they also hide the searchbar to give more space to the contents, but that's a detail that is not applicable to FSearch) and none of them minimize (or exit) the window when pressing Esc.

¹: Sure, panel-type launchers (especially those that can be globally and instantly spawned at any time with a hotkey, because they are part of the window management system) and utility sub-windows that are children of an app's main window, can be expected to be hidden or closed with Esc... however FSearch is not a panel-style launcher (or even a launcher at all, in my view), it's a full fledged app that is expected to retain its presence and be reused multiple times in a row. It's not easy to spawn & focus "out of the blue" with a single keystroke (unlike GNOME Shell's "just press the Super key"). The expectations are therefore quite different for this type of app than if it was part of the window management system. Esc to dismiss the window is not helpful in the case at hand, as it is unexpected and if I wanted to do that type of action I'd use one of the gazillion window manager's shortcuts (Alt+F9 / Super+H, Alt+F4 / Ctrl+Q, Ctrl+W, etc.) so we really don't need to hijack Esc for this when it can fit the more standard "clear the search" pattern seen in other standalone apps...

[nekohayo]

I needed a quick way to give users feedback that the deletion was successful, even when the search results didn't reflect that.

I don't know how close to the "ideal backend implementation scenario" you are (i.e. if it will make it into the next release or if it may be deferred), but if you still need a stopgap UI feedback mechanism by the next release, you might want to consider a desktop notification (ex: the equivalent of notify-send --app-name="FSearch" --expire-time="5000" "File successfully deleted." or maybe through a cleaner API call over dbus if you don't want to just call a random command) instead of a dialog; that way it's not blocking the UI with a dialog that needs to be dismissed, and it's self-cleaning.

[cboxdoerfer]

As for other applications that follow the same principle: Nautilus, DevHelp, Yelp, GTG, GNote, Gedit, Builder, Epiphany, Firefox, LibreOffice, Shortwave, etc. all clear the search on Esc (and since search is not their sole purpose, they also hide the searchbar to give more space to the contents, but that's a detail that is not applicable to FSearch) and none of them minimize (or exit) the window when pressing Esc.

Ok so having Esc clear the search field indeed sounds like a reasonable default. But I'm still not sure if I want to get rid of the options to have it also exit or minimize FSearch, before the custom shortcuts manager is ready, which would allow users to assign arbitrary actions to Esc. Simply because I know that some users use that option and it wasn't me who implemented it.

I don't know how close to the "ideal backend implementation scenario" you are (i.e. if it will make it into the next release or if it may be deferred)

The next release will have the "ideal backend implementation scenario", which will make this dialog obsolete.

that way it's not blocking the UI with a dialog that needs to be dismissed, and it's self-cleaning.

I already have a solution in mind to get rid of most of the blocking dialogs for errors, warnings and feedback. The idea is to have in-app-notifcations instead, similar to Nautilus and a log panel, where many actions (search, open file, delete file, database refresh, ...), their timestamp, return value and some context are listed.

[nekohayo]

The idea is to have in-app-notifcations instead

Oh yeah, you could indeed use GtkOverlay for that; there's even a simple proof-of-concept python app over there you can draw code inspiration from ;)

[cboxdoerfer]

Oh yeah, you could indeed use GtkOverlay for that; there's even a simple proof-of-concept python app over there you can draw code inspiration from ;)

Thanks, that looks like a great inspiration.