On Sunday 19 June 2005 01:46, [EMAIL PROTECTED] wrote: > There are also other things that bother me about Ctrl+L dialog, > namely the implementation of autocompletion and the fact that > if you type the full path to a file, you still have to > confirm the selection in the open dialog itself.
Before I respond to this, I want to make it plain that I don't consider the Qt/KDE dialogs especially "holy" in any sense. If you use GIMP on KDE (as I do), it's almost painfully obvious why people refer to it as a GNOME application: it *looks* like one. Yes, it is only the GTK libraries, really, but components like the file-open dialog look quite alien when compared with practically everything else. This by itself is not a real problem, although undesirable. The issue for most people, I'm guessing, will be that the whole flow of the dialog is alien to everything else around it as well. It has the whole "dumbed down but if you click on Advanced enough times you might get somewhere" feeling, compared to the relatively cluttered and intimidating (but also efficient) KDE dialogs. This is something which (as a techie) I don't find too disturbing, but which drives my wife completely twittery. She is an artist and a musician, not a techie (which is one reason I'm interested in doing artistic brushes for GIMP). I've "tricked" her into using GIMP for cropping and scaling images for EBay, but the alien appearance of the file-open dialog gets it categorised in her artistic little brain as being completely different to a KDE dialog aimed at exactly the same set of files. > I need to compile the list of things that bother me about the > GTK+ file chooser and submit it to bugzilla someday. I know I'm > not the only one being bothered with it's design. Agree. But I'm not sure that changing the existing GTK dialog as such would be as useful as offering user-configurable alternatives, which is why I spoke of a "zero overhead" shim. Using such and compiling GIMP would by default result in binaries identical to the current ones, but you could use it to (at compile time) invoke alternatives in some places, one of which could concievably be a (no longer quite zero overhead, you'd have to at least bounce each call through a table) run-time choice of default GTK, alternate GTK or Qt-through-wrapper. By default, GIMP remains unchanged, but for those annoyed or panicked by differences, the option to erase the most disturbing differences would be available. Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/ Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/ Member, Linux Australia _______________________________________________ Gimp-developer mailing list [email protected] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
