Re: File selection dialog changes



Erik Andersen wrote:
> 
> Hmm.  I had to pull an all nighter at work last night, so maybe I can
> get off work early today and code something up.  Mostly I like how under
> NT, the CFileDialog allows you to right click an any file and then
> open it, add it to a zip file, change its security settings, cut it,
> copy it, delete it, rename it, create a new directory, change the amount
> of detail shown about the files, create a symlink (NT "shortcuts"), or
> send the file via mail, etc.  It does this without adding in extra buttons
> to clutter the normal case, while still acting as a mini file manager.
> The things that the CFileDialog can do on a right click are defined by the
> context of the click (if it is on the background, a directory, or a file),
> and the functionality is provided via a COM interface.

Yipes!  Think this one through very carefully!  Consider the
following quote from the Interface Hall of Shame, in a section
devoted specifically to addressing the faults with Windows'
common dialogs:

http://www.iarchitect.com/file95.htm

>   Attention Deficit Disorder 
> 
> An application uses the common Open File dialog simply
> to allow you to specify the file to be worked on.  Why 
> is it then, that the Open File dialog allows you to 
> rename files, delete files, create new folders, send 
> files to the printer, send a fax, save a file to a 
> floppy disk, try to convert a bitmap file to an Excel 
> spreadsheet, edit a file with a different application, 
> create an e-mail message. and so on, all while the 
> calling application is waiting for the name of the file 
> you want it to work on? This is bizarre! 
> 
> While you could do all these things and more from the 
> Open File dialog, who would want to? The availability 
> of these functions from this location could only be of 
> extremely limited value to the most experienced of users, 
> at the cost of easily confusing the new user. These 
> functions are not mere distractions, they could lead the 
> user on a convoluted path through the operating system, 
> taking them further and further away from the initial task. 

IMHO, this feature should stay out of GNOME proper, unless it
passes the approval of the core GNOME developers (which I doubt
will happen).  It's a can of worms, and probably not the best way
to go.  This functionality belongs once, in the file manager, not
duplicated in every application.

In any case, I agree (with Jeff) that it should not go into the
v1.0 release.  

Later,
John

P.S.--To shed some light on my comments, I'm also a MFC hack at
work and a Linux geek at home, pining for a 100% Linux
existence.  (c:



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]