Sven Neumann <s...@gimp.org> writes:
> On Sun, 2009-01-04 at 01:24 +0100, Heinrich Moser wrote:
>> I don't think I will further investigate this, since I don't see much
>> point in this, to be honest. Yes, we could find out what's taking
>> GIMP's file open dialog so long and make it be as "fast" as other GTK
>> applications. But I really think the time is better spent solving the
>> problem permanently (like implementing the above mentioned plug-in)
>> rather than fine-tuning something that can never be as fast as the
>> native OS implementation.
> The above mentioned plug-in will always only be a kludge as it can't
> provide all the features that an internal file dialog offers. So the
> focus should be on fixing the GtkFileChooser. There is absolutely no
> reason why it can't be as fast as the native OS implementation. After
> all it is using native OS-specific code.

Well, that's how it should be in operating systems. To be honest, I
don't think this is the case with Windows. Microsoft is well known for
using undocumented OS features to make their applications more
performant than their competitor's, so I guess they'd do that even
more in something they consider part of the OS (rather than an
application or a library), such as the file chooser.

Nevertheless, as a user of GTK-based products, I really appreciate
your effort on motivating people to improve GTK. And I don't want to
leave this discussion without giving a big THANKS to all gimp
developers for making such a great product!  Please consider my
request for a Windows file open/save dialog as an improvement
suggestion (or as a plug-in suggestion, in case any motivated C
developers read this) and not as criticism of your work or of your
design decisions.

Best greetings from snowy Austria,

Gimp-user mailing list

Reply via email to