Re: Clipboard

In the sole intrest of usability, I would personally have a problem with the 
changed cut/copy/paste icons -- instead of changing the standard icons, (if 
the application supports it) you should turn on the "Icon + Text" toolbar 
setting.

Changing the cut/copy/paste icon is like changing the shape and size of a Stop 
sign... you just can't do it.  However, you can write "STOP" on it to make it 
more effective to those who are unaware of what a big red octagon on the side 
of the road means.

I also think the idea of a Klipper menu by holding "paste" is excellent and 
would in fact enhance the usability of applications requiring lots of 
copy/paste operations (Kate, etc.).

	- Matt


On Sunday 04 August 2002 10:58 am, Friedrich W. H. Kossebau wrote:
> 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  :)