Clipboard
"Friedrich W. H. Kossebau" <[email protected]> Sun, 04 Aug 2002 16:58:38 +0200
| Newsgroups | gmane.comp.kde.look |
|---|---|
| Message-ID | <[email protected]> |
Hi everybody! Once again I couldn't concentrate on the important things and was lead away by the annoying mouse support of the clipboard within KDE. Here is the result: As you can see on all the screenshots on kde-look.org and elsewhere noone seems to change the order of the clipbpard buttons on the toolbar. Even the symbols might have never changed since their introduction anno domini (was it ms word 4.0?). But is this due to usage tradition, or is the concept really the best? I doubt the later. When in mouse mode and about to work with the clipboard I always find myself to stop for a moment to remind what symbol is what (yes, I DO work almost daily with a computer ;) So I worked out an alternative solution. The reasoning is as followed: 1. Both actions "copy" and "cut" have in common the adding of something to the clipboard. Thus they both have an element that shows the adding: the moving paper. The difference is quite obvious shown: copy leaves the original, cut leaves an empty place. Seems more obvious to me than a scissor and the doubled paper (haven't tested for small sizes like 16x16, though). 2. Look at the old copy symbol. The new paper moves to the left. But the clipboard symbol is usually at the right. Now I think it makes more sense if the cutted/copied paper moves in the direction of the clipboard symbol. 3. I placed one action to the right, the other to the left of the clipboard symbol. Maybe this placement makes it easier to associate the action also with the place. This way you can already start to move your mouse cursor into the direction of the clipboard symbol while remembering what is where. Arrived at the position of the clibboard symbol a simple move to the left or to the right will reach your aim. 4. The kicker applet "klipper" is nice, but ouf of my work flow. Why not offer the whole usable klipper content via an additional dropdown menu on long button click, like with the navigation buttons of konqueror? 5. I am not sure about this: Wouldn't it make more sense if the clipboard is not greyed out if no content is available but shows the status by an empty clipboard? The clipboard could be greyed out if inserting is not possible, like in readonly mode. I really like my idea. It breaks tradition, but look at the attachment: Isn't the new solution a step forward in usability? So, what do you think about this? Friedrich PS: And would be more eyecandy than usability: When copying and inserting via the clipboard the movement of the data is visualized by a flow to and off the clipboard from and to the actual placement in the document view... like the window movements to and from the taskbar when hiding/unhiding :)
tools_old.png
(image/png, 5.5 KB) - not displayed
clip_new.gif
(image/gif, 6.6 KB) - not displayed