View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001982 | Double Commander | Graphical user interface | public | 2017-12-30 02:03 | 2021-10-29 23:21 |
| Reporter | kandrey89 | Assigned To | cordylus | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Projection | none | ETA | none | ||
| Platform | MacOS | OS | OSX | OS Version | 10.13.2 |
| Product Version | 0.8.1 | Product Build | 7950 | ||
| Summary | 0001982: File Search with Brief View Navigation style Causes Issues with Selecting Files | ||||
| Description | When I have a Brief View nav mode with 4 columns, and 3 columns are showing within my pane. I start typing a letter and a search box opens up at the bottom of the pane with the letters, the navigation select also changes to the first found file based on the search, so far so good. I see the file I want, it's in the 3rd column, I hover my mouse to it and click on it once. Problem: The whole list gets shifted because the search bad closed and now my click landed on another file, and I lost visual of the file I wanted. You can't reshuffle the list like that on users, very frustrating. I can't think of anything else right now other than making the file search a permanent part of the pane, or provide extra space for the search to appear and disappear, that way the extra space is always therte and it doesn't trigger a list reshuffle. | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | 8923 | ||||
| Operating system | MacOSX | ||||
| Widgetset | QT4 | ||||
| Architecture | 64-bit | ||||
|
|
I agree that it's annoying, took me some time to get accustomed to quitting the search (Esc or Tab) before doing anything with mouse. Maybe add an option to always show the quick search panel? |
|
|
Other possible solutions: - Make search window floating, like in TC (although I'd prefer to see current file details, so place it under the details panel). - Don't hide the panel when unfocusing in brief view, hide it only manually or on view change. Something has to be done, using quick search in Brief view is a pain currently. |
|
|
First variant has drawbacks: if status bar, command line and F* buttons disabled, window maximized and task panel not at bottom then float window will hide the bottom file. |
|
|
Agreed on the first variant. Although it can also float to the top right corner, like the search page UI in Chromium browser. But that wouldn't fit well when the window or panel width is small. If only we combine the two approaches (float on top and on bottom) based on circumstances, this solution could be viable (unless DC is run on a really lowres 800*600 screen) Another option is to move the mouse to the new position of the element that was under the mouse cursor before the click. But I don't like this idea, it seems unclean to me. And the last one, developing on the second variant: don't hide when unfocusing (unless by keyboard?), hide on: directory change, opening (viewing, editing) file, maybe on keyboard move? |
|
|
For me, a solution that moves the mouse is a non-starter. It's very rude to the user to move his mouse cursor. Doing that only a few times could cause the user's mouse to run out of room and require mouse repositioning on the mat or table. Why not follow what TC has done and what has worked for decades? Here's an option that keeps DC's search bar: Keep the search bar always visible at the bottom, this avoids having the navigation panel resizing. The search bar is fairly small, so I think keeping it always ON is not a big issue compared to reshuffling the entire file list in the panel when switching between typing in the search bar and clicking on the file. I mean if I am searching for a file xxx123.png, in a panel that has a hundred files, some of which start with xxx, then when I type xxx and I see my xxx123.png file, when I go to click on it, the search bar closes, the file list gets reshuffled, and I end up clicking on thew wrong file. That's TERRIBLE! |
|
|
> Doing that only a few times could cause the user's mouse to run out of room and require mouse repositioning on the mat or table. Good point, I didn't like that idea anyway. > First variant has drawbacks: if status bar, command line and F* buttons disabled, window maximized and task panel not at bottom then float window will hide the bottom file. I've checked how TC works in this case, it does show it over the bottom line indeed. So either we accept this as a lesser evil or agree on some condition for not closing the search. What do you think about not hiding it automatically until directory change when the panel is in brief view mode? Just this simple, all other view modes are vertically scrolled and not a problem. I've thought that the less reshuffle the better, so now propose to not touch it with any other actions like those I've listed in my previous comment. A separate question is whether the search should be automatically cleared at the time it was previously closed. |
|
|
I think to avoid reshuffling, it should always be open. Basically, DC has extra features in the implicit pane search, features we probably want to keep. If we don't "need" to keep, then we could make it work just like TC, where you start typing letters, and the selection cursor just starts going to the first found file name, without any search bar or indication what the search string is. In order to keep these features and avoid reshuffling, the search bar needs to always stay open. I think the search term should remain in the search bar after deselection/defocus, the existing features like Filter, {}, etc should be persistent and be remembered (remember last setting). What do you think about using Esc key to clear the Search Term when the search bar is selected/has focus? |
|
|
Finally, fixed. rev.8923 This was the most annoying bug for me for quite some time. When in brief view, plain unfocusing won't hide it anymore, will hide on: Tab from it, Escape (from the file list too), clicking X button, changing directory, changing view to column or thumbnails (only if unfocused, filter is preserved). Otherwise the behavior is unchanged - when unfocusing, search is cleared, filter is applied if not cancelled. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-12-30 02:03 | kandrey89 | New Issue | |
| 2017-12-30 03:34 | cordylus | Note Added: 0002484 | |
| 2018-10-30 04:08 | cordylus | Note Added: 0002848 | |
| 2018-10-31 22:08 | Alexx2000 | Note Added: 0002854 | |
| 2018-10-31 22:08 | Alexx2000 | Status | new => acknowledged |
| 2019-06-14 18:43 | cordylus | Note Added: 0003176 | |
| 2019-06-14 18:45 | cordylus | Note Edited: 0003176 | |
| 2019-06-21 02:31 | kandrey89 | Note Added: 0003183 | |
| 2019-06-23 01:34 | cordylus | Note Added: 0003185 | |
| 2019-06-25 23:08 | kandrey89 | Note Added: 0003191 | |
| 2019-06-29 04:31 | cordylus | Fixed in Revision | => 8923 |
| 2019-06-29 04:31 | cordylus | Note Added: 0003195 | |
| 2019-06-29 04:31 | cordylus | Status | acknowledged => resolved |
| 2019-06-29 04:31 | cordylus | Resolution | open => fixed |
| 2019-06-29 04:31 | cordylus | Assigned To | => cordylus |
| 2019-06-29 04:33 | cordylus | Note Edited: 0003195 | |
| 2021-10-29 23:21 | Alexx2000 | Status | resolved => closed |
