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
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