[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: BeOS and KDE compared: screenshots of trash and file context
From:       William Leese <yatsu () wanadoo ! nl>
Date:       2003-01-28 4:24:24
[Download RAW message or body]

Uno Engborg wrote:
> On Monday 27 January 2003 20.25, William Leese wrote:

[snip]

>>>Hrm, wait a second. Why not:
>>>
>>>Copy to -> Clipboard
>>>Move to -> Clipboard
>>
>>Just to get back on this. While it adds an extra click to the cut &
>>paste process it allows people to move/copy things easily without having
>>to resort to our (currently) slow and clunky (for simple file
>>management) filemanager.
>>
>>A nice compromise I think. Ofcourse the "Clipboard" entry should be on
>>top of the option list and easily recognisable. So you'd have something
>>like:
>>
>>[Open]
>>[Open With ..]
>>[Add ins ..]
>>--------------
>>[Copy To ..]  -> [Clipboard]
>>[Move To ..]     [Home]
>>[Rename]         [Root]
>>[Delete]         [Trash]
>>--------------
>>[Properties]
>>
>>This allows us to eliminate 'Copy', 'Cut', 'Paste'  and 'Move to Trash'.

Trash shouldn't be there.. my bad. Also, 'Paste' can't be removed. 
'Paste' should be 'Paste from Clipboard'.

> It fills the same function as Apple spring loaded folders.
> I'm not sure what the Clipboard does though.

I'm not familiar with these spring loaded folders. What are they?

The purpose of an entry for the clipboard is to temporarily store the 
file so that the user may browse to the destination (of which the user 
was uncertain / which is not permanently accessible. For example a 
non-mounted network share).

> I also think that "Delete" should not be in a standard menu as this is a 
> destructive action you would like to make sure the user doesn't do by 
> mistake. It would be better if the delete behavior could be a setting in
> "Properties" dialog in Trash. (see previous mail)

There's a warning to make 'Delete' pretty hard to do on accident. It's 
also a often used function.

> I also think that making a file go away, either by selecting your "Delete" 
> item or "Move To"->"Trash" is very different from moving files in general.
> To the user this is a removal action not a move action.

You're right about 'Delete' ofcourse, but I never mentioned it. Not sure 
how 'Move to ..' -> 'Trash' differs from 'Move to Trash' though.. (this 
is how it works on my machine atleast).

> If we have Copy To, and Move To I would also like to have Link To. Even though 
> it gives us one more menu item, it sort of belong there. I also suggest 
> reordering Move To and Copy To so that the most used choise comes first.
> 
> 
>  [Open]
>  [Open With ..]
>  [Add ins ..]
>  --------------
>  [Move To ..]  -> [Home..]
>  [Copy To ..]      [Root ,,,]
>  [Link To...  ]	  [Browse ...]	   
>  [Rename]          -------------	
>  [Trash]		   [/last/selected/directory]		
>  --------------          
>  [Properties]
> 
> 
> Here I removed the Clippboard mostly because I really don't understand what 
> its for. I also added a Browse item to call up a file dialog where you could 
> select a location.  By using a filedialog it is possible to move things to 
> ftp and sftp servers  etc.  This is about the same thing  that the kuick 
> konquerer plugin does right now.

I'm not familiar with the plugin. But if it is easily accessible then we 
can ditch the clipboard and it's related context menu items for all file 
objects.

- wvl

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]