Re: UI Rantings [was: Re: gmc and file-selection mockups]

["James M. Cape" <jcape jcinteractive com>]

"Jesse D. Sightler" wrote:
> 
> >> I don't quite see your point here.  Are you saying that the gmc "files
> >> panel" should be a separate component (neither a part of GMC nor the File
> >> Dialog)?  That seems like a pretty low-level implementation issue to me,
> so
> >> I'm not sure what the exact answer is, but my guess is that you are
> probably
> >> correct.  :)
> >
> >That's exactly what I'm saying. If the File Selection Widget (aka the
> >files panel) is going to be used in more that one part of Gnome, than it
> >should be part of Gnome-libs, not Gmc. The reason for this is simple --
> >why load Gnome-libs *and* Gmc when all you want to do is open up a file
> >in Gedit?
> 
> Remember what I said about "low-level implementation isssue[s]".  I think
> that it applies here.  :)  Adding a separate library to gnome-libs or adding
> a "libgmc" to Gmc are identical actions from a size/efficiency standpoint.
> Where exactly they should go is more a matter of programmatic convenience
> than one of efficiency.
> 
> In other words, just because it is a library doesn't mean that is MUST be in
> gnome-libs.  Of course, gnome-libs must not be dependent upon the existence
> of gmc in order to function.

Well, same difference. It's a cleaner and simpler solution to put it in
Gnome-libs IMO (if it must be there -- which hasn't been proven to me
yet). I personally disagree with the idea of having interchangable file
selection widgets, because nothing else is widget independent, and
adding that uncertainty is not necessary at all. I completely agree that
leaving it in Gmc and making Gnome-libs and Gmc cross-dependent is not
an answer.

> >> Then we had better not do much.  :)  Seriously, "the most inexperienced"
> >> users still have trouble with adequately controlling mice and
> understanding
> >> that there are such things as context sensitive menus.  I know people who
> >> have used Word/Wordperfect for Windows for years without ever knowing
> that
> >> they could print a file without first opening the application and then
> >> opening the document and then clicking print.  :)  We can't build the
> user
> >> interface completely to the lowest common denominator no matter what we
> do.
> >
> >Why can't we? I'm not saying don't include anything new users can't
> >understand. What I'm saying is that don't confuse new users with even
> >more complexity if you don't need to.
> 
> And all I am saying is that I do need file open, print, delete, rename,
> copy, and move functionality from open file dialogs.  Just make sure that it
> doesn't waste screen real-estate or confuse new-users.  :)

You open a copy of the Open Dialog to print something. That is behavior
you learned from Win9x, and because you've gotten into a bad habit of
doing it, would like to be able to do in Gnome as well. I completely,
firmly, and undeniably disagree with this idea, because it is completely
counter-intuitive, and new computer users (not just new Linux users)
should never find anything that forms bad habits. Don't copy
bad-habit-forming things from Windows just because they are there and
you have made it a bad habit. Break your bad habit, don't spread it to
others.

Copy and Move are grey areas, and I personally wouldn't object to them
because they can be useful.

Delete and Rename need to be there, IMO.

However: Cancel should undo *all* changes. Period. I don't care if
Windows does it wrong, Cancel should *always* return *everything*
(*including* the filesystem) to it's original state, as if the dialog
had never been opened. I can't possibly stress this one single point
enough.

> L8r,
> 
> Jess

    Jim Cape
    http://www.jcinteractive.com

    "All animals are equal, some animals
     are more equal than others."
         -- George Orwell, Animal Farm