Linked by Thom Holwerda on Wed 11th Jul 2007 21:15 UTC, submitted by Johan Thelin
KDE A quick look at the state of KDE 4, including screenshots. "Over all, KDE 4 alpha 2, was a pleasant experience. Not much worked on a user level, but large parts of the underlaying infrastructure seems to be in place. I'm looking forward to the more releases and the final version due in October."
Thread beginning with comment 254852
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Disappointed
by Narishma on Thu 12th Jul 2007 10:01 UTC in reply to "RE[4]: Disappointed"
Narishma
Member since:
2005-07-06

The drag & drop popup won't be fixed because it's not a bug but a feature and many people prefer it to how it's done on other desktop environments. This way you don't have to guess if it will copy or move.

The animated tooltip you can already disable in KDE 3.5.x, and kicker won't be in KDE 4.0 anyway.

Reply Parent Score: 5

RE[6]: Disappointed
by unoengborg on Thu 12th Jul 2007 13:43 in reply to "RE[5]: Disappointed"
unoengborg Member since:
2005-07-06

The drag & drop popup won't be fixed because it's not a bug but a feature and many people prefer it to how it's done on other desktop environments. This way you don't have to guess if it will copy or move.


I don't think MacOS-X, Windows, or Gnome users guess what will happen when dragging a file. From the desktop metaphor perspective, 'move' is the expected action.

It is however still a bug that this behavior is not used consistently for all drag and drop situations involving moves or copying in KDE. I don't like the menu, so personally I'm glad that they don't, but that doesn't make it less of a consistency bug.

In fact, if the reason for the menu was that users should know what would happen, this menu would be even more needed when dragging text in a document where the desktop metaphor is less obvious than when dragging things on the desktop.

In these situations the menu wouldn't be as bad as on the desktop as we here only have to deal with 'move', 'copy' or 'cancel'. In other words, the menu would contain options that users quite frequently would select (perhaps with the exception of 'cancel'), as opposed to when dragging files where you have also have the 'link here' option that almost never gets used.

Another problem with the konquerer/dolphin pop up is that the 'link here' operation is completely hidden. Imagine you were blind and navigated your desktop by the keyboard and a voice reading you the text on the menu. How would you find out how to make a link as you most likely would move/copy files by doing cut,copy and paste operations. So at the very least there have to be some other way of creating links that was reachable from e.g. the 'Edit' menu. Speaking of links, why is there no way of making a hard link?

The windowing environment that handles this best is probably Microsoft Windows. It creates a pop up menu, similar to the KDE one, on right menu button drag. This way the user can easily chose in what situations he wants the menu or not.

The secret of making good user interfaces is to keep simple things simple. If you have dialogs or menus where some of the options are used very rarely this is a good indication that you should consider some other design. On my filesystem less than 1% of all files are links, and most of them are made automagically by e.g. install scripts. This is an indication that at the very least that if the pop up is kept, that option should be moved elsewhere. One solution could be to use cut or copy and add a 'paste as link' menu item to the 'Edit' menu. That would also have the advantage of making it fully visible.

Even if this menu is popular by many users, it have serious usability issues.

Reply Parent Score: 2

RE[7]: Disappointed
by richmoore on Thu 12th Jul 2007 14:09 in reply to "RE[6]: Disappointed"
richmoore Member since:
2005-08-06

I don't think MacOS-X, Windows, or Gnome users guess what will happen when dragging a file. From the desktop metaphor perspective, 'move' is the expected action.
Well, on windows the action depends on the relative locations of the source and destination. If they're on the same device it moves, otherwise it copies - not exactly obvious!

Reply Parent Score: 5

RE[7]: Disappointed
by joeprusa on Thu 12th Jul 2007 22:33 in reply to "RE[6]: Disappointed"
joeprusa Member since:
2006-05-25

We keep battling one problem on Windows again and again at work: someone inadvertedly moving a whole directories around, usually with a touchpad. How much would I love to have the menu with a "Cancel" option!

Reply Parent Score: 2