Hello,
after working with the Prof version for some days now, the most annoying thing for me is the following:
xplorer2 is set here to not automatically shift the focus to view after activation and the focus really is in the folder-tree after selecting a folder there.
But there is always also a ghost file-selection in the file list (sometimes greyed out), which causes the ugly partly dotted border arround one file (although that full row selection is not activated here). This ghost selection also causes that when I switch to the file list and click the Modified column to sort for files, the newest files at the top are not always visible, because xplorer2 tries to keep the ghost selection visible.
It seems that xplorer2 first sets the focus to the file-list and selects the full row, then it handles my setting to not select full rows and switches to select just the first column (what leaves the partly dotted border), then it switches back to the folder-tree without unselecting the whole file-list.
Maybe it is also possible to fix the Shift-Click on Delete button, so that deleting without Recycle Bin becomes possible? If the toolbar cannot be locked, what about a seperate Kill button?
Bye and have a nice weekend
More design questions
Moderators: fgagnon, nikos, Site Mods
The dotted line at a place where it should not be is just cosmetic, true, but it looks "unfinished" and confuses.nikos wrote:#1 is 100% cosmetic; when inactive a pane draws the focus "full row" which is very useful for comparing details when in mirror browsing/scrolling mode
The auto-selection in the file list is not cosmetic, because it is present (and not done by the user). Example:
1. Execute xplorer2
2. Select the Windows folder
3. "C:\WinNT" is highlighted in the tree-list here and the folder "$NtUninstallKB329115$" has the dotted "cosmetic" border.
4. Now press the "Modified" column. I expect to get a date-sorted list with the newest date visible at the top of the file-list.
5. What I get is a date-sorted list, but the first visible file/folder is not the newest, because the list scrolled down to keep "$NtUninstallKB329115$" visible.
So I have to scroll up again to get what I want, just because xplorer2 does some kind of auto-selection in a list, which should not be focused at all according to my settings.
This would be great, because I do not change the toolbar as much as I delete files. Anyone there for the necessary next request?nikos wrote:#2 if i get another request like that i'll disable shift-drag in toolbars altogether
BTW: sorry for my english.
That's what I'm trying to explain the whole time. I did not select/focus anything in the file-list. I just selected a folder in the folder-tree, which displayed the files in the file-list. It was xplorer2, who selected a file/folder automagically.nikos wrote:>but the first visible file/folder is not the newest
x2 always tries to keep the focus visible
No, as I explained in my last post, it happens also after a fresh start.nikos wrote:this could have been the file you last browsed in the folder, or the file you were most interested in
No, this means: I have switch the focus to the file-list, put the mouse away and use Ctrl+Home, just to get the expected effect.nikos wrote:in your case it involves the slight inconvenience of having to press Ctrl+Home to get back to the top
When I did not select any item in the file-list before, there is no need to force additional clicks or key-strokes to get a proper sorted list with the newest file visible at the top.
Again: I have not set the "Shift focus" option.
Nikos, I do see a strange effect which I was not aware of earlier when there is nothing actually selected in a pane. When no files are selected and only the dotted line is visible on a file, when you navigate away from that folder (either using tree or other means) and then return to the folder, the item which first had 'focus' but was not selected is now selected!!
I think it is by design. I do see the point rogers is making that 'follow focused item' can be annoying when changing the sort order. The philosophy of following the focused item is a good one generally.
But when you change sort order, most of the time you do this to make it easier to navigate or select blocks of files having similar attributes (be it name or modification date or whatever you are sorting on).
Keeping the focused item in view seems to be less important to me in such cases, so maybe it should be made configurable to keep track of focused item, giving three possibilities:
1. keep focused item in view always
2. keep focused item in view except when changing sort order
3. don't keep focused item in view at all
Of course (1) being the default (as it behaves now)
Something for september?
I think it is by design. I do see the point rogers is making that 'follow focused item' can be annoying when changing the sort order. The philosophy of following the focused item is a good one generally.
But when you change sort order, most of the time you do this to make it easier to navigate or select blocks of files having similar attributes (be it name or modification date or whatever you are sorting on).
Keeping the focused item in view seems to be less important to me in such cases, so maybe it should be made configurable to keep track of focused item, giving three possibilities:
1. keep focused item in view always
2. keep focused item in view except when changing sort order
3. don't keep focused item in view at all
Of course (1) being the default (as it behaves now)
Something for september?
Dumb questions are the ones that are never asked 
Absolutely true, ... when it was the user who actually selected an item. In my example it is xplorer2, that selects for me.JRz wrote:I think it is by design. I do see the point rogers is making that 'follow focused item' can be annoying when changing the sort order. The philosophy of following the focused item is a good one generally.
...
This would most probably fix the problem when 2. or 3. is checked, but it would be just a work-around which would not solve the problem with accidently selected files or folders when 1. is checked. I do not know what kind of other things may happen with this auto-selection beside just disturbing a sorted list, but an application should not select files by itself.JRz wrote:Keeping the focused item in view seems to be less important to me in such cases, so maybe it should be made configurable to keep track of focused item, giving three possibilities:
1. keep focused item in view always
2. keep focused item in view except when changing sort order
3. don't keep focused item in view at all
Of course (1) being the default (as it behaves now)
...
when there's no prior selection, x2 automatically focuses on the first file; this is necessary for the internal consistency of the program state
i don't think this is a big deal
most of the time it works for your advantage
in the rare cases like sorting after reading, you can go back to the top using the keyboard or the mouse (grab the scroller and drag it to the top)
not to mention the extreme alternative of selecting the sort order before moving in a folder
ps i tried to remove shift-drag from the toolbar, but it isn't possible. I can remove the effect but then the click is just eaten and nothing happens. There is an option to have Alt used in place if Shift, but that's going to be even worse since Alt is used for bookmarks and other things
i don't think this is a big deal
most of the time it works for your advantage
in the rare cases like sorting after reading, you can go back to the top using the keyboard or the mouse (grab the scroller and drag it to the top)
not to mention the extreme alternative of selecting the sort order before moving in a folder
ps i tried to remove shift-drag from the toolbar, but it isn't possible. I can remove the effect but then the click is just eaten and nothing happens. There is an option to have Alt used in place if Shift, but that's going to be even worse since Alt is used for bookmarks and other things
A lot of clicks and mouse moving for something that Explorer easily does.nikos wrote:...
in the rare cases like sorting after reading, you can go back to the top using the keyboard or the mouse (grab the scroller and drag it to the top)
not to mention the extreme alternative of selecting the sort order before moving in a folder
But you could invoke the SHFileOperation API with FO_DELETE (without FOF_ALLOWUNDO) from a new "Kill" button or when SHIFT is clicked (GetAsyncKeyState) in the toolbar area and the mouse coordinates are in the area of the Delete button. This should also work when the development-environment does not allow the same effect, because the system manages this. ... Just in case someone else asks the same again.nikos wrote:ps i tried to remove shift-drag from the toolbar, but it isn't possible. I can remove the effect but then the click is just eaten and nothing happens. There is an option to have Alt used in place if Shift, but that's going to be even worse since Alt is used for bookmarks and other things