From: Sven Neumann <[EMAIL PROTECTED]>
Date: Wed, 22 Jun 2005 10:12:05 +0200
Robert L Krawitz <[EMAIL PROTECTED]> writes:
> Sven, you've been offered a solution -- just add an entry with tab
> completion. You may not agree with it, but it's not accurate to say
> that "noone has made a proposal on how such an entry should be
> integrated with the current dialog". Just stick it on the bottom of
> the dialog, just above the OK/cancel boxes, and Marc and I will be
> happy to shut up.
This is not about making you and Marc shut up. This is about
designing a user interface that works for the majority of
users. Whatever we do, there will always be someone complaining. I
don't really care who that is.
This one seems to be attracting a disproportionate share of
complaints. Usually with other controversial interface issues I see a
few comments, and then people start to converge. This one is
> In what way is "just adding an entry with Tab completion going to
> ruin the whole thing"? If it's there, but isn't used, it isn't
> going to interfere with anything else, is it?
It does indeed interfere with the rest of the dialog, otherwise it
would probably have been added a while ago already. But I already
explained the problems of this approach in another mail that I sent
If I understood correctly, it's a conflict between the use of tab for
completion and tab for jumping between widgets? If so, how about
using a different keystroke for completion (escape or ctrl-tab, for
Perhaps another approach would be for the integrated text input to be
initially hidden, but with a "More>" button that makes it visible.
The state of the "More>" button is saved, so that the next time the
dialog is popped up it has the same components as it did before.
> And why is it so important that there be a concept for the entire
> dialog beyond "what works best for people"? The problem (to me,
> and I daresay to Marc) is very simple -- there's no obvious way
> to simply enter a pathname with a simple form of completion
> that's only activated on demand. A file dialog without this is
> just plain fatally flawed.
The problem is to find out what works best for people. Trying to
decide this in an argument among developers is very certainly going
The problem is that there's no one method that "works best for
people". People like Marc and I find the old dialog much more suited
to our needs than the new one.
> Make it a configuration option, if you like.
No, I don't like configuration options, I hate them. And it would
also not have to be me who adds it but the GTK+ developers. We are
certainly not going to fiddle with the internals of the
Obviously the problem is a GTK issue, not a GIMP issue.
> My first experience with the new configuration dialog was absolutely
> brutal. I couldn't believe that I was being presented with a file
> dialog that had no text entry box (I spent a while exploring it to try
> to find the button that would give me the entry box), and given the
> way I jumble everything together, searching around in a list entry is
> hopeless (I have about 1000 files in one directory; I know a lot of
> the filenames by memory, but being forced to do a linear search
> through that many files is simply absurd). I more or less stopped
> using the GIMP altogether for a while; I used Cinepaint or xv (!)
> despite it being obsolete in many ways where I could, and otherwise
> started a new instance of the GIMP each time I had to use it, because
> dealing with the file dialog was so hopeless. Eventually after poking
> around Google I found the ctrl-L hack, but it's still very clumsy
> compared to the simplicity of a text entry box.
I agree that the Ctrl-L is clumsy and I would like it to be removed
(of course after it has been completely obsoleted). But you don't
really need Ctrl-L to use the dialog. I am sorry that you made your
first experiences with the new dialog with the early versions that
were indeed rather akward to use.
Two problems with this:
1) There's no visual cue that typing in a filename will do anything.
2) The secondary popup is very annoying (either it's going to pop up
under the mouse, in which case it's going to obscure other parts of
the dialog, or it isn't going to have focus for those of us who use
focus strictly follows mouse).
Robert Krawitz <[EMAIL PROTECTED]>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
Gimp-developer mailing list