Version: 3.2.2 (using KDE 3.2.3, (testing/unstable)) Compiler: gcc version 3.3.3 (Debian 20040422) OS: Linux (i686) release 2.6.4-mnj8 In Detailed List View the area where files are being marked (selected, opened, etc.) is too big to comfortably manage directories with a variety of files with short and long names. If only one file with a very long name is included in any given directory the "Name" column resizes to completely display the name of this file - just as it should. The problem is that any file is being marked if you click anywhere on its "Name" column - not only if you click on its name or icon. So to get the right-click menu or mark multiple files with the mouse you have to start such an action on some other column than "Name" - for example the "Size" column. Suggestion: If the free space of the "Name" column (blank area after the name) would allow to start those actions (marking multiple files, right-click menu) instead of selecting the file it should improve overall usability. There has been a bug report here thats slightly alike: http://bugs.kde.org/show_bug.cgi?id=47584 But it is definitely different because SELECTING files should IMO also be based on their name and icon - not on the column which is bound to confuse users as there is no real hint that the whole name-column equals the file (normally its: file = icon and/or name of the file) and it is completely different in Icon View and MultiColumn View. Fixing this would increase consistency throughout Konqueror. Here are screenshots of the described behavior: 1. single file showing the area to interact with this file (current): http://www.deadhand.com/kde/images/mark_files_area.png 1. single file showing the area to interact with this file (suggestion): http://www.deadhand.com/kde/images/mark_files_area_new.png 2. selecting multiple files (current) http://www.deadhand.com/kde/images/mark_files_select.png 2. selecting multiple files (suggestion) http://www.deadhand.com/kde/images/mark_files_select_new.png 3. start selection within name column (suggestion): http://www.deadhand.com/kde/images/mark_files_select_new2.png 4. start folder-oriented rightclick action within name column (suggestion): http://www.deadhand.com/kde/images/mark_files_rightclick_new.png
Created attachment 6884 [details] Patch to fix #84087 Clicking on a blank area of the list item now highlights it, but does not execute it. You can also now safely start dragging a rubber band from this blank area. This patch directly applies to KListView, so it will have effects on programs other than Konqueror. I think this will be a good thing, but if anyone disagrees then I can probably move it to the Konqueror list view class.
This is a good thing, also for other applications. If you can make sure that clicking before the name, on checkbox for instance, also doesn't execute, it would fix bug 71367.
I still didn't get around to load and compile a KDE with this patch applied - and most probably won't during the weekend. But I'll definitely have to soon - especially need to see how it handles because it's a bit different than what I imagined. I thought it might be good to only mark the filename, but the way the patch is done it might 'feel' just as well - don't know yet. Anyway thanks for taking the time to fix this!
Hm, I'd like a screenshot
I've commited this patch to CVS.
Patch works like a charm. From what I have seen of 3.3 (live CD), konqueror doesn't resize the name column past a certain point even with a very long filename in the directory. In other words there isn't ever really a time when no columns other than name are visible. This patch is a godsend for 3.2 where sometimes all you can see is the name column, but on 3.3 doesn't seem as necessary: thre is always somewhere to right click without it. Without it each file is also "the same size" as far as launching etc goes, and offers a larger area for clicking, which IIRC were the reasons things were changed so the whole column could be clicked in the first place. Anyway, those goals are abandoned now, just in time for 3.3 when the fix isn't truly needed like in 3.2 :D Belive it or not, I like the change though. Thanks
I've finally had a chance to check out the change myself - and I have to agree it works really good. Even though it might not be 'absolutely necessary' in 3.3 due to the changed behavior you described I think it's a much more expected and "natural" (heh yeah... on a computer) behavior if you can rightclick on free space and get the folder context menu (to paste for example) and have to click the filename or icon to actually open a file or get to it's context menu.
Is it possible to quickly change the area that is being marked when you click on the file/column for 3.3? I think the current behaviour is a bit misleading, since it kind of promotes the idea that you could click the whole column to activate the file (which isn't what most users expect and has been addressed anyway) since it marks the whole column, not just the icon and filename. To fix this the marked area could be limited to the icon and filename like in this mockup: http://www.deadhand.com/kde/images/mark_files_select_new2.png
I submitted bug 88964 because of my observations in #8. I have been talking to two people now who were confused as to why their selected files were suddenly not selected at after they seemingly clicked on them (though they only clicked on the free space that has been marked).