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

List:       kde-usability
Subject:    Re: Abstracting the Linux Desktop from the File-system
From:       Ralph Gottesbuehren <gottesbuehren () web ! de>
Date:       2002-12-06 18:40:20
[Download RAW message or body]

Am Freitag, 6. Dezember 2002 15:22 schrieb Uno Engborg:

> If we make the popup optional  we should change the order of the menu items
> so they were ordered "Move", "Copy", "Link".  That way the user would do
> less mouse movement since the "Move" choise is by far most common.

No reason against that.

> We also don't need a "Cancel" item. It is inconsistent with other menus,
> and the user will have one more unecceary choise to worry about. The user
> can just as well click somewhere outside the menu just like he does if he
> cancels any other menu in KDE.

right.

> And I don't think using the menu should be the default option. New users
> that might not know what a link is shouldn't be forced to make a choise
> wether they wan't to link or not.

most users switching from ms-windows know what a "link" could be ( i think). 
there it is called "shortcut" and its often in use.

> > -The left button dragging menu should show accelerator key. It was
> > pointed out that this is not possible cleanly so far which should be
> > considered a bug and fixed asap. After doing so users will see what keys
> > they can use to avoid the menu (and maybe optionally turn off the menu
> > altogether in the control center).
>

do you know, that you can avoid the menu right now in kde 3.0.3 by pressing 
acc.keys? shift+mouse for moving, ctrl+mouse for copy and no pop-up menu 
appears. so the functionality you want is always there, but not the default.
i personally never knew that before this evening...

hmm, and while you copy with ctrl+mouse, there also appears a nice little "+" 
aside the mouse-pointer?

seems that there was the same discussion ages before...

greeting,
ralph


> But this only apply if we keep the old behavior with a pop up menu.
> The suggestion was to remove the menu. It would still be a  bug only if we
> keep an option to use the old style.
>
> > -An additional reason why I think it'd be stupid to hide the left button
> > dragging menu by default: In Windows I found a Japanese freeware archiver
> > program called Noah which integrates itself into the right button
> > dragging menu and thus allows you to compress dragged files into an
> > archive file at the dragged target as well as decompress the content of
> > dragged archive files into the dragged target. KDE's left button dragging
> > menu could offer a similar ability. But if it's hidden by default never
> > will ever see it, and introducing new accelerator keys for this kind of
> > additional features would be stupid.
>
> As windows raises the menus on RMB up instead of RMB down, they have more
> options.  In windows you press the RMB and if you have dragged the object
> before releasing the button you will get the move menu, and if you don't
> drag before releasing you get the context menu.
>
> As we can't differentiate between the  RMB context menu and the RMB drag
> menu this would not not be possible. And as far as I no are no programs
> that attaches themselves to the KDE move menu this is not an issue. Forcing
> every user to make one extra mousclick whenever they move somthing, just
> because some program in the future might need a menu to append something to
> doesn't make sense.
>
> If you was to do something similar to your  archiver , it would probably be
> better to add the compress functionality as a service menu to the object to
> be compressed. And then move the compressed file just as usual.
>
> > In Windows I'm using the right button dragging menu as default since I'm
> > used to drag files around on a miniature interface. The menu gives me the
> > ability to ensure that I hit the correct target before starting the
> > action (targets should be highlighted, everything else is unnecessary
> > fuss). And as of late decompressing and compressing files was what I did
> > more by dragging than moving, copying or creating shortcuts (call it this
> > way instead links).
>
> Agree, that would be much more visible than the method used today.
>
>
> Regards
> Uno Engborg
> _______________________________________________
> kde-usability mailing list
> kde-usability@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
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]