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 different. > 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 last night. 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 example)? 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 to fail. 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 GtkFileChooser widget. 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." --Eric Crampton _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
