Summary: | In Tree/Detailed List View empty space in 'name' column is treated like a real entry | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Christoph Wiesen <cwiesen> |
Component: | file icon view | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 3.2.2 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Patch to fix #84087 |
Description
Christoph Wiesen
2004-06-27 14:26:12 UTC
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). |