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
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to