On Wed, 22 Jun 2005, Robert L Krawitz wrote: > Date: Wed, 22 Jun 2005 07:32:11 -0400 > From: Robert L Krawitz <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: gimp-developer@lists.xcf.berkeley.edu > Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of > GIMP > > 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.
It is unfortunate that the new file chooser is bad at exactly the things the old file chooser was good at, a case of six of one half dozen of the other. (I always have a terminal open and make frequent use of gimp-remote so I dont mind to the new file chooser too much.) > > 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. > Obviously the problem is a GTK issue, not a GIMP issue. There seems to be a big benefit to developers in using the new File Chooser API. I am a little surprised no one has ported the old file chooser to the new API, or written any alternative file choosers that work with the new API. (There was definately some talk of adding support for the KDE file chooser to use the Gtk File Chooser API by developers connected with Freedesktop.org or Redhat I think but I am pretty sure nothing ever came out of those wild ideas but the Gtk Developers would be the ones to ask I guess.) I notice some projects have added support for the new file chooser to make it a compile time option but mostly as a way to avoid forcing their users to use the latest version of GTK. I expect the gimp requires an up to date version of GTK for other other reasons but perhaps support for the old file chooser could be added as a compile time option (horribly inelegant and another unpleasant configuration option I know but I wanted to put it out there as a possibility). - Alan H. _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
