Bug 47584

Summary: Clicking on empty space in konq's detailed list view should not open any files
Product: [Applications] konqueror Reporter: joup
Component: generalAssignee: Konqueror Developers <konq-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: cshobe, maksim
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: All   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description joup 2002-09-07 21:18:52 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           konqueror
Version:           KDE 3.0.3 
Severity:          normal
Installed from:    compiled sources
Compiler:          gcc version 2.95.4 20020320 [FreeBSD]
OS:                FreeBSD (i386) release 4.6-RC
OS/Compiler notes: 

Konqueror's behavior in dealing with mouseclicks to its detailed list view is incorrect from a UI standpoint.  

To get an idea of what I'm talking about open konqueror to your home directory and click View|View Mode|Detailed List View (or Tree View or Text View; the same behavior applies).  Your files will be displayed in a list with the filename on the left and the size of the file (right-justified to its column) in the 2nd column.  

The correct behavior here is for a mouse click anywhere on the TEXT OF THE FILENAME to open/run that file.  The problem is that clicking anywhere in the "Name" column will open/run the file in that row even though the user only clicked on "empty space".  

(Quick side note: In "Text View" clicking in ANY of the column will open/run the file in that row.)

It's perfectly for a click anywhere in the row to SELECT that file but it should not open/run it.

Thanks
Mark Miller

(Submitted via bugs.kde.org)
(Called from KBugReport dialog. Fields Application manually changed)
Comment 1 Unknown 2002-09-16 05:35:46 UTC
This is of course a matter of opinion. For the following reasons, I believe the    
current behavior is more correct:    
    
1) Selection is shown on the whole column.    
2) It would be more difficult for the user to judge when a click would open and   
when it would select if it depended on the variable width of the name.  
3) If you have it turned on, there is a nice cursor feedback as to what action   
will be taken.  
4) Larger targets are easier to hit. (Fitts law)  
 
I welcome additional feedback from the kde-usability team. 
Comment 2 John Firebaugh 2003-09-22 03:14:38 UTC
*** Bug 63591 has been marked as a duplicate of this bug. ***
Comment 3 raditzman 2004-01-17 18:33:18 UTC
I agree with the poster of this bug.
I  *never* clicked outside the filename or icon when I used konqueror in detailed list mode. There is no feedback (besides the cursor, which is insuficient) that told me I could click anywhere to select the filename to the left. In fact, I only discovered that it worked like that when I tried selecting a few files, and  ended up dragging the one to the left where I clicked.
- Completely unpredictable (I assumed that in *any* filemanager, a file is a file, and an empty space is not) 
- and completely un-userfriendly (there is no way (at least *obvious and immediate*) to select files using a mouse in this view).

 I think this beavious goes against all gui-theories out there.

Comment 4 Michael Brade 2004-08-24 12:30:13 UTC
This was fixed recently. I don't know if it's fixed for KDE 3.3 already,
but I think so. If not, it'll be in KDE 3.4. Clicking on the filename
directly will execute it, clicking everywhere else will select it.

Cheers,
  Michael
Comment 5 Clarence Dang 2004-08-24 14:19:33 UTC
On Tue, 24 Aug 2004 08:30 pm, Michael Brade wrote:
> This was fixed recently. I don't know if it's fixed for KDE 3.3 already,
> but I think so. 
Yes, it is.

> Clicking on the filename directly will execute it, clicking everywhere else
> will select it.
The former is IMHO a massive improvement but the latter is still confusing - 
esp. since Konqueror still incorrectly highlights the entire column.  I was 
double clicking in frustration (expecting the old broken behaviour) wondering 
why Konqueror wouldn't open my file.

Comment 6 2006-04-11 14:08:00 UTC
this isnt fixed and im using branch_3.5 revision 528451, so how was this marked as fixed?