Re: First UI component needing replacement.

[Dylan Griffiths <Dylan_G bigfoot com>]

Ken Fox wrote:
> I'm not talking about entering a file pattern here. The <?> is a
> command that asks the file dialog to refresh the file list with only
> the files that are interesting to me. The highlighting of files can
> happen automatically, but removing files from the display should be
> a user requested command.

AFAIK, F5 is always the shortcut to refresh in any file manager I have
seen.  I think you misunderstand in that there will be a list of files, and
they will be filtered when you enter a regexp and press enter in the text
entry box.  Not "automagically" refresh, as the ? key would be used for the
"single unknown character" in the regexp.
 
> I don't want to see a crippled file dialog just because the functionality
> appears in the file manager. We should put all the commands necessary
> to find and select a file into the file dialog.

And I don't want to see a bloated common file dialog because the user might,
someday, possible use some feature.  I want to implement what makes sense,
not what we can.

http://www.jwz.org/doc/worse-is-better.html
 
> > There you go, giving multiple meanings to different keys based on the
> > context.
> There I go. ;) The computer has such a pathetic low bandwidth user
> interface that it's almost impossible to avoid context-specific
> interpretation of keystrokes. You already said that <space> can scroll,
> or activate a button or cause " " to be inserted in a text field.

Yes, but those are separate controls.  You can class that as one behaviour
still because each control reacts in one way.  The door knob either turns or
doesn't, it doesn't drop off and scurry into a corner.  I'm just going for
the principle of least surprise :-)

This will change once more users are experienced with computers, but it is
too early.  And besides, we need to get Gnome to a basic quality state.  I
was playing with KDE today, and they kick our asses.  Faster, more
consistent, and running on x86 OpenBSD (something Gnome cannot do because of
assumptions it makes).  They kinda beat us by cloning most of the widgets
from Win32, whereas GTK+ uses annoying Motif-ish things.  (Personal
snigglet, I prefer those vertical and horizontal bars which allow resizing
parts of the window from anywhere, rather than just one little box on the
line near one end)
 
> If you look at the mental state of a someone using a file dialog they
> are going to be in one of two modes: (1) looking for a file to open
> or (2) looking for some place safe to save data. If hitting <space>
> fails to auto-complete it can either beep or insert the space
> depending upon which conceptual mode the user is in. That's not a
> significant problem. Understanding and recovery is fast in either
> case, so why not choose the most useful possible error mode?

You are thinking modal text dialog from Emacs, jah?  The save and load
dialogs are separate, but act as similar as they can.  The user will most
likely use their mouse to browse via the provided tree and listviews.  I
agree that some of your keyboard shortcuts are good, but you are taking it
too far (to the point where you'd hinder normal operations, IMO).
 
> You quoted the anti-mac article and now you slavishly appeal to
> the mac status quo?

Why get users who like to run when we can't provide a lower gear for the
greatly larger population?

Seriously, look at Irix.  Yes, crap implementation, but I can do everything
"simple" I want without ever using a command line.. something not really
possible under Linux.  I've even been playing with plans on how to make a
copy of Slackware behave in that fashion for local experimentation.  To the
point of considering how to write the boot loader :)
 
> Your average user probably doesn't know how to type either so why
> would you design a keyboard interface for him?

s/him/them/.  The keyboard interface isn't crappy because each key is
labeled as to their equivalent functions, except for the meta key.  (Yes,
this includes the space bar -- blank is very much the label for space :)). 
The mouse is the crappy one without properly labeled buttons, leading to
strange differences in different places.

I want Gnome to be able to work with the Mac-level people.  And at the flick
of a switch, I want it to be able to get out of the way for the advanced
users.  Ever try to turn off delete confirmation in Windows (as well as that
"recycle bin)?  Doesn't work.  I've even developed the habit of hitting
enter after delete.  If you grew up with that, I can understand how you'd
think advanced and simple interfaces are mutually exclusive, but that is
simply not the case.
 
> I don't want to enter patterns in the file name field. That's
> confusing because if the file name is a pattern what gets sent to
> the application when I press the OK button?

True.. but then there needs to be a way of switching between mime type and
regular expression fields.  Besides, ls ?ave*report.txt works in the same
fashion as ls savenue_report.txt, it's just the results are different.  In
this case, OK would apply the regular expression to the files.  This would,
of course, be documented -- the dialog will only return with a name once all
ambiguity has been cleared.  The user can filter the noise files, and select
the one they want.

> The file type can certainly support sophisticated MIME types and user
> defined file patterns. In fact, the line should be very blurry so that
> users can extend simple file patterns with (Scheme, Perl, etc.) code
> to make them into advanced types.

Extendible, sure.  Hidden from a beginniner user?  Yes!  This would be
something we should include in an "advanced" file dialog that could be a
choice..

IE: Normal dialogs, or Advanced ones.  Advanced ones lets you pick extra
behaviour from a list to add, as well as try them out with an example
dialog.  This would let people grow over time, and customize their dialog
behaviour.  I know I'd *hate* to have some of the stuff you talk about, but
other stuff I could find myself using almost constantly.

Most OSes let you choose fonts and colours, let us be the first to let you
choose it so that it grows WITH you! :-)
 
> Conceptually it makes sense to use the same file dialog for anything
> which resembles a file system. I'd like to know in what respects you
> think FTP is different from a local file system. Performance? In that
> case you must want a different browser for floppy disks. ;)

No No No No No No NOOOO :)

FTP is not at all like a local file system.  I will not have embedding a
bloody FTP client in a damned file dialog.  Add a Linux kernel module that
lets you hook the VFS such that you have a userspace daemon that allows you
to "mount" FTP directories like you'd mount an NFS or Samba share.. but
whatever you do, don't put that in a common dialog.  That's just SICK! :)
 
> If the implementation is busted then we should fix that instead of forcing
> different user interfaces for the same "find a file to open" user task.

"Find a file to open in the Unix VFS directory tree" would be a billion
times simpler.

The right tool, for the right job.  Add some piping, and we have the
equivalent of a large, monolithic application for the price of none, and
with a greater flexibility in banging out other nifty functionality.
 
> I've not used mc, but I have used other virtual file interfaces. (One of
> which I built in perl so I know performance isn't a big problem.)

This is the kind of statement I read an laugh aloud from.  "This is the pain
I feel when you do FTPFS in a common file dialog because Perl does it fast"
:-)

The right tool, for the right job.  An FTP mounting daemon would be the
correct way of solving this problem, and I'm one of those "correctness or
death" kinds of guys ;)
 
> > That Would Be Bad :)
> 
> In what ways? If the user interface isn't complicated by these advanced
> features I can't see any way that this is Bad. We're talking about a
> shared library which is probably already memory resident -- no code bloat
> to worry about. We're talking about an interface that brings the browsing
> to the application instead of forcing somebody to jump to a different
> application and back again. The growth pattern from point-and-click to
> keyboard usage is simple.

I'd rather than instead of bloating user space with shared libraries that
duplicate the functionality in a kludge way, we just add the functionality
to the kernel.  Think packet socket interface, think how user mode NFS
works, etc.  Have the VFS provide the hooks, and then get a user space
daemon to handle that stuff.  It'd be simple to have a "mount.ftp" and
"mount -a -t ftp" and have it use something like /etc/ftpmounts and do keep
alive, etc, with much more simplicity.

Do you decide that to add more plugs, you should daisy chain power bars?  Or
do you do the better approach of running more outlets from the panel?

:)
 
-- 
    www.kuro5hin.org -- technology and culture, from the trenches.