[OT] Re: Usability of the GTK+ 2 file open dialog

[Michael L Torrie <torriem chem byu edu>]

On Wed, 2006-03-08 at 12:29 +0200, Tor Lillqvist wrote:
> David Necas (Yeti) writes:
>  > Sorry, but this is BS.  Stop pretending all MS Windows apps
>  > use the very same file open dialog, that is just not true.
> 
> Indeed. I would say that the more expensive an application running on
> Windows is, the more probable it is that it has a long history, is
> written using goddess knows what user interface libraries, and doesn't
> use the Microsoft "widgets", for instace file open dialog. Case: CAD
> and EDA software, where license and support fees can easily be in the
> range of thousands of dollars per seat per year.

Sure but these are extremely niche applications.  If you wanted to
produce a mainstream application (say a word processor or an image
manipulation program), users expect a file open dialog box that looks
pretty similar to what the other programs in Windows do.  Of course all
windows apps don't use the exact same file open dialog box.  But most
look and act pretty much like the win32 standard one.  A casual survey
of a local windows boxes reveal no applications (we have Notepad, MS
Word 2003, QuickTime Player, Quicken, OpenOffice 2.0, Firefox)that has a
file open dialog box that looks substantially different in behavior and
function from what the standard Windows XP dialog looks like, except for
the Gimp.  Some have the shortcuts bar on the left and others don't.
Some have a third drop-down box on the bottom.  But all of them have the
standard input boxes and behave as the user would expect as he types in
paths and file names, or points and grunts.  The "look-in" drop-down,
which I dislike intensely, is as one would expect.  Only the Gimp is out
of place on this desktop in this regard.

I won't advocate that GTK on windows forcibly overriding the gtk dialogs
with the win32 equivalents.  But any programmer that wants his or her
GTK apps to be taken seriously on Windows (outside of the expensive,
old, niche markets) should consider #ifdef'ing in the win32 calls where
appropriate.  It is just common sense to integrate with the host OS's
standar UI as much as possible, where a host UI standard exists.
Developers might also want to consider changing their dialog button
orders to be more consistent with the host UI too.  I prefer the gnome
HIG on this (and Mac), but on Windows I know that this drives users
nuts.  I think Win32 should be the one to change, but that's probably
not going to happen.

Even under Linux, once such things become possible, I think GTK apps
should be using KDE dialog boxes if the user's KDE desktop is set to ask
that of GTK apps (IE if the user wants it), and vice versa.

I've marked this comment as off-topic because it doesn't have anything
to do with GTK directly.  And certainly nothing to do with the GTK file
selector dialog box.

Michael

> 
> --tml
> 
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>