Bug 68975

Confirmed on CVS from 2003-11-24.  But I'm not sure whether this
is a bug or not.  Right-clicking (which selects a file), and then
Paste sort-of implies pasting onto that file, which doesn't make
sense.  BTW, you get the Paste action if you right-click on a 
directory or on a blank area of Konqueror.

The problem is that in Tree View for e.g. /bin there is no blank space ...

In 3.1.4 rightclick a Name of a directory - the directory is selected and a cut/copy/paste context menu is given.
In 3.1.4 rightclick a Size of a directory - the directory is NOT selected and a paste context menu is given.
In 3.1.4 rightclick a Name of a file - the file is selected and a cut/copy context menu is given.
In 3.1.4 rightclick a Size of a file - the file is NOT selected and a paste context menu is given.

In 3.2b1 rightclick a Name of a directory - the directory is selected and a cut/copy/paste context menu is given.
In 3.2b1 rightclick a Size of a directory - the directory is selected and a cut/copy/paste context menu is given.
In 3.2b1 rightclick a Name of a file - the file is selected and a cut/copy context menu is given.
In 3.2b1 rightclick a Size of a file - the file is selected and a cut/copy context menu is given.

The following related behavior is identical in 3.1.4 and 3.2b1.

Setup two treeviews and:
Drag a directory from 1) to a directory on 2): when dropping on Name the pointed to directory is selected and the copied directory ends up in the pointed to directory, when dropping on Size the pointed to directory is NOT selected and the copied directory ends up in the "parent" directory. 
Drag a directory from 1) to a file on 2): you can drop on any column BUT Name and the copied directory ends up in the "parent" directory.
Drag a file from 1) to a directory on 2): when dropping on Name the pointed to directory is selected and the copied file ends up in the pointed to directory, when dropping on Size the pointed to directory is NOT selected and the copied file ends up in the "parent" directory. 
Drag a file from 1) to a file on 2): you can drop on any column BUT Name  and the copied directory ends up in the "parent" directory.

I know the above two comments are difficult to read  ;^)
But the base line is that when there is no blank space in the Tree View the 3.1.4 behavior is workable, whereas the 3.2b1 behavior is not ...

Created attachment 3524 [details]
3.2b1 rightclick on directory.Name

Created attachment 3525 [details]
3.2b1 rightclick on directory.Modified

Created attachment 3526 [details]
3.2b1 rightclick on file.Name

Created attachment 3527 [details]
3.2b1 rightclick on file.Modified

Created attachment 3528 [details]
3.1.4 rightclick on directory.Name

Created attachment 3529 [details]
3.1.4 rightclick on directory.Modified

Created attachment 3530 [details]
3.1.4 rightclick on file.Name

Created attachment 3531 [details]
3.1.4 rightclick on file.Modified

I just found out that in 3.2b1 in a "full" tree view there is no way to create a new directory/file via rightclick :((
To be honest, one can create a new directory/file via Menu > Edit > Create New. 

This bug is becoming a showstopper for me - please set the priority to grave.

Summary
=======
In Icon, MultiColumn and Info List View when one rightclicks on an item (directory or file) a context menu for that item (highlighted) is shown. When one rightclicks on a blank space a context menu for the current directory (Create New, Paste) is shown.
In Tree, Detailed List and Text View for a big directory there is no blank space and any rightclick gives a context menu for that item (highlighted).
In 3.1.x this dilemma was resolved by treating any column other than Name as blank space.

Please treat this useability bug as grave.

3.2 Beta 2 - and this USABILITY bug is still not even confirmed ...

3.2 RC1 - and this USABILITY bug is still there - it is not even confirmed ...
It looks like I will have to stick to 3.1.5 for quite some time to come ...

This same problem is in release!!!!!
This _is_ showstopper!!!

I think I fixed it in HEAD. If it works, I'll backport to the 3_2_BRANCH

Alex

Dear Alexander,
Thank you for the update.
I am eagerly awaiting the 3.2 backport!
Kind regards, Dick

3.2 final still has this.. At the very least it is inconsistant.  You cannot only open a file with left click in the name column, but right click in ANY column gives you the file's right click menu with no possibility to paste or create a new directory.  

I'd call it a showstopper.  I won't use 3.2 on my everyday distro until this is fixed.  This bug is set to Resolved?  Hopefully without sounding like a jerk: where?  What do I need to do to get a version without this bug?

Dear Alexander,
I noted your commits for this bug in the KDE_CVS_Digest of Feb 13, 2004.

I downloaded the seven complete sources the diffs in the commit for the KDE_3_2_BRANCH point to, copied them to my kdebase-3.2.0 build directory and started a make. Alas that make failed on the first compile: konq_listviewitems.cc:254: no matching function for call to `KonqFMSettings:: caseSensitiveCompare(QString, QString)'.

I then downloaded the diff that looked the most promising:  konq_listviewwidget.cc -r1.226.2.2 -r1.226.2.3, applied this diff to my (restored) kdebase-3.2.0 build directory and did a make (no problems) and make install.

These are the results:
1) When *no* directory or file is selected a rightclick on a non-name column now indeed gives a paste context menu - choose paste and the file is copied to the current directory. Hurray!
2) When a directory or file *is* selected a rightclick on a non-name column still gives a cut/copy context menu for the selected item. One has to explicitely unselect (shift leftclick or via the Edit menu) the directory or file and then rightclick on a non-name column again to get a paste context menu.

The explicit unselect is stil awkward, but when compared to the switch to icon view to find some free space to rightclick on (and the switch back to listview) that was required before the patch things have improved significantly. For me the *showstopper* has become a mere *nuisance*.

In 3.1.x a rightclick unselected whatever was selected. It would be nice if this behavior were re-instated.
Kind regards, Dick

Reopened for the request to make a rightclick unselect whatever was selected.

The context menu behavior in detail list view is indeed a bug.

Regarding right-click should deselect selection, I hope this
refers to right-click performed on place other than the "Name"
column.

right click with full list view lets you paste now, this has been fixed.  But there is still no possibility to create a new file or folder.

When first entering a full directory and no file is selected it is possible, but once a file is selected, right click on columns other than name no longer deselects a file, so one cannot create a new file or folder.  

using 3.2.2

As a workaraound, press Esc to "unfocus" the filename. Then, when you right-click at other fields, you'll get the correct context menu.

*** Bug 57645 has been marked as a duplicate of this bug. ***

CVS commit by binner: 

Backport konq_listviewwidget.cc 1.239
CCMAIL: 68975-done@bugs.kde.org


  M +1 -1      konq_listviewwidget.cc   1.226.2.4


--- kdebase/konqueror/listview/konq_listviewwidget.cc  #1.226.2.3:1.226.2.4
@@ -798,5 +798,5 @@ void KonqBaseListViewWidget::slotPopupMe
 {
    kdDebug() << "KonqBaseListViewWidget::slotPopupMenu" << endl;
-   popupMenu( point,true );
+   popupMenu( point,false );
 }
 

Dear Stephan,
Your May 9 fix indeed resolves the remaining nuisance of having to unselect explicitely.
Thank you, Dick