Morten Welinder

Federico is bringing up the file chooser’s lack of speed again. Good.

The first step, IMHO, should be to get rid of reloading the folder
of widget mapping. It is wrong to do non-widget, expensive and externally-visible actions in a widget mapping handler. If someone
switches to another virtual screen and back (for example to peek at something),
do we really want to reload the folder? Do we lose the selections
in the process? If The Gimp wants that behaviour, I say it can
install a handler and trigger it itself.

Would things appear to be faster if we installed a single-shot
idle-handler that created a file chooser and threw it away?
(That would be a work-around more than a fix, of course.)

There is more to your item 7 than just performance, btw. It should
not stat() all those parent directories because it may not be allowed
to do so. If you just succeeded in stat(“/foo/bar/baz”) then
it should not be necessary to check that “/foo” and “/foo/bar” are
directories.

Robert, I said “int”, not “long”.
The code you presented does not work for platforms where the two are
different. There is no strtoi so you get to use strtol and do the
extra range checking.

It also does not work because there is no
requirement that strtol set errno for any condition
but overflow and underflow. In particular for the empty string.

It also does not work because libc functions may
set errno when no error is detected. And, in fact, they
often do.

And, finally, it also does not work for strings like “010″.
You get 8, but you should get 10 when someone mumbles “decimal”.

Update: And while I am picking at you, it seems I
have to point you at the ctype man pages too. isdigit
is defined on the special value EOF and an integers within the range
of unsigned char.

In practice, what libc implementations do is something like

  #define EOF (-1)
  #define isdigit(_c) ((__somearray+1)[(_c)] & SOME_BIT)

That can and will core dump if you send a random signed character.

(Glibc has a misguided attempt at making things work for signed
characters also. They essentially add 128 and duplicate half the
table. That works fine unless you want the right answer.)

It is time for a gripe.

Libc contains a lot of quite APIs. You probably know about the
gets dissaster, but there is a whole lot more.

• String-to-value conversions. Here is how you
  convert from a string s containing a decimal integer
  into an int i:

    char *end;
  
    int i;
  
    long l;
  
    errno = 0;
  
    l = strtol (s, &end, 10);
  
    if (s != end && *end == 0 &&
  
        errno != ERANGE &&
  
        l >= INT_MIN && l
  
  And that is before considering locales (which typically do not
  
  affect integers, mind you).
  

• Time zones. The localtime function
  is great, but having $TZ as as implicit and not explicit argument
  makes it really, really hard to use for anything but the default
  time zone.
• ctype functions. At least two things are wrong:
  (1) the encoding used is an implicit argument; and (2) they are defined obscurely such that char c = 'a'; isdigit(c) may or may not
  be valid, depending on the platform. Most commonly it is not valid,
  i.e., it may core dump. The right way to do that is,
  for reference, isdigit((unsigned char)c) which is enough to make a sane man crazy. (Alternatively one
  could define c as unsigned char but in
  more practical code the type is often constrained by a parameter type.)

I have the feeling I might return to this subject later.

In the grand tradition of nntp-over-rss, let me kick in a word or two
about file choosers. Start by reading what Federico — wrote on the topic.

Regarding Emacs, Federico missed a few important things. (Any description of Emacs that is smaller than the tar ball is incomplete, naturally.)

• Case: Completion in Emacs is (optionally, this being Emacs) case insensitive. This is very useful if you are lazy
  with the shift key or just happens to get a lot of filenames via a
  telephone.
• The Tab key will, after completions have been listed, scroll the completion window when you press it again. (I actually wrote that a decade or so ago.) This makes it possible to
  navigate large directories fairly easily. A drop-down like the one
  the GTK+ file chooser provides is not useful for this. Note, btw.,
  that this feature also makes completion useful in keyboard-only mode.
• A completing Tab that ends up with multiple choices left does not also list the choices
  for two reasons: (a) it is slow on a 9600 baud terminal and (b) if you are just using the Tab key to speed up entry you generally do not
  want the list of possible matches until you are not making progress. The latter is still valid and
  prevents the UI from getting in your way. The FileChooser’s
  completion is very much getting in the way: it steals focus and
  obscures parts of the dialog you want to see.

In my experience this means that the Emacs completion is useful while
the FileChooser’s is not. That is especially true in directories with hundreds of files. (And that is before we discuss bugs that cause people to overwrite files they did not intend. The current state of save-as is somewhere between “barely usable” and “dangerous to your files”.)

On opening files: suppose I want to add a “gtk-button-images = 0″ setting in ~/.gtkrc-2.0. Why do I have to use two different UIs depending on whether that file already exists? The logical extension of that would be to have two entirely
different UIs for save-to-new-file and overwrite-existing-file; we
are lucky no-one in Redmond thought of that, I guess,
This should not be too hard to fix — I will have a go at it in a
while.

On screen real estate: The GTK+ file chooser gives
me a vew of 7-8 files (typically directories, actually) when it comes
up. To locate a file I have got to scroll which is a bit hard with
such a small viewport. Emacs, on the other hand lists files in
batches of 36 files. Guess which one I find more useful. (This
is actually for a large part a treeview issue.)

All the above comes through a little more negative than I really
wanted it to. I do appreciate all the work that Federico has put
into the FileChooser. My goal is not to assign blame for where we
are — that would be pointless or worse — but to get us to a better state.