The behavior you describe happens in Open mode.  There, I think it makes sense to automatically complete the longest common prefix of the files that match, since you can only select *existing* files anyway.

In Save mode, that kind of automatic completion doesn't happen; you have to invoke it explicitly by pressing Tab.

There's a detailed explanation of this rationale here: http://primates.ximian.com/~federico/news-2005-05.html#completion-annoyances

There used to be some bugs in old versions of GTK+ where completion was *really* annoying, and the auto-highlighting lost track of your keystrokes sometimes.  What is the exact version of GTK+ that you are using?

Thanks for that link , it explains nicely where thinking is in what you're doing.

>> We have inline completion because Windows people expect it. Inline completion happens 

I'm sorry, I find that comment worrying. 

Autocompletion should be there if it works efficiently and it is helpful.

Care should be taken not to downgrade the linux experience to accommodate windows users who expect everything to be identical except the price tag. ;)


Yes it is true that I can only open an existing file. Tab completion would be a nice feature if I want a short-cut.

If autocompletion is there (and I believe I have not option on that) it should be implemented in a way that does not effectively prevent me from simply typing in a file name if I wish.

Maybe something could be done to reduce the visual interference of how this works. The hightlighting could be slight tonal change rather than inverse video and the position of the text cursor should remain the main focal point of the eye when inputting text.

All this movement : type ahead , inverse video on/off, drop down lists etc. is very disruptive. If something drops down my eye gets pulled away , I mentally evaluate what is there then get back to what I was doing.

That's animal instinct, genetically hardcoded. You _must_ take that into accound when designing a user interface.

All the good ideas are wasted if they end up getting in the way.

I hope these comments help you in designing an efficient interaction with these dlgs.

Regards.

So, to confirm:  are your complaints only about OPEN mode, or about SAVE as well?  (there's no auto-completion in SAVE mode).

Well there's no text type ahead but there is the drop down list of possible completions . I find this more distracting that the flashing text since I actually forces my eye to drop to read the list.

Have you ever noticed how annoying flashing banner ads can be? Why? Because they contantly pull your attention away from what you are trying to do. And that's _why_ they flash.

I think these would be nice features if supplied on demand at the touch of a key (suggest tabkey for tab completion or down arrow for the list.) 

So to that extent my comments apply to both forms of the dlg.

regards.

I just passed this by someone who is also a fairly good typist. She found 
it as aweful as I do. This feature seems acceptable only for people who type 
with two fingers and need to look at the keyboard each time they hit a 
key. 

For that reason they are not affected by the display jumping around. They
aren't even looking!

The tab-completion on which this is modeled uses , surprise, the tab-key.
That would be a nice line to follow, it is not without merit.

It would be good if gnome did not confine it's target audience to complete 
gnumb-gnuts who can't save a file without calling thier mommy or their 
social-worker.

If gnome desktop wants to take that line, I can choose to avoid it , but 
it should not apply to all programs which are built on the gtk+ library.

*** This bug has been marked as a duplicate of 307802 ***