From kde-usability Tue Jan 28 04:24:24 2003 From: William Leese Date: Tue, 28 Jan 2003 04:24:24 +0000 To: kde-usability Subject: Re: BeOS and KDE compared: screenshots of trash and file context X-MARC-Message: https://marc.info/?l=kde-usability&m=104372798015628 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