HI,

On Sat, 2009-01-03 at 17:35 +0100, Heinrich Moser wrote:

Is it possible to make GIMP use the "default" Windows File Open/Save dialog*, for example, by setting some secret configuration option?

No. And we are certainly not willing to add such an option.

The reason that I want this is because the GIMP dialogs are terribly slow when accessing a slow (e.g. VPN) UNC network path (= \\IP-Address\Share\directory\...).

You should report this as a bug against GTK+ then and perhaps you will also want to help the GTK+ developers to isolate and fix the cause for this.

Sven

2009/1/3 Heinrich Moser :

Is it possible to make GIMP use the "default" Windows File Open/Save dialog*, for example, by setting some secret configuration option? I remember that there was a plug-in for this a long time ago (which added "Windows Open" and "Windows Save As" menu options) but I cannot find that anymore.

There seems to be a NIH syndrome in many programs, Gimp included, where the devs feel (possibly rightly in many cases) that they must reimplement core OS functionality. File Chooser dialogs are among the most visible (and annoying) of these cases. Although you use Windows, here is my Kubuntu bug about the situation: https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/281834

Dotan Cohen wrote:

2009/1/3 Heinrich Moser :

Is it possible to make GIMP use the "default" Windows File Open/Save dialog*, for example, by setting some secret configuration option? I remember that there was a plug-in for this a long time ago (which added "Windows Open" and "Windows Save As" menu options) but I cannot find that anymore.

There seems to be a NIH syndrome in many programs, Gimp included, where the devs feel (possibly rightly in many cases) that they must reimplement core OS functionality.

Hi,

GIMP not reimplementing core OS functionality, we are using the GTK+ library so that we can care as little as possible about OS specific things. Your point about inconsistent file choosers is still valid but I don't really see a trivial solution. Keep in mind that GIMP's usage of the file chooser is more involving than just firing up a dialog to get a file path. It would not be feasible to maintain the code that interacts with the file chooser for multiple file choosers, at least not with the current GIMP developer resources.

BR, Martin

2009/1/3 Martin Nordholts :

There seems to be a NIH syndrome in many programs, Gimp included, where the devs feel (possibly rightly in many cases) that they must reimplement core OS functionality.

Hi,

GIMP not reimplementing core OS functionality, we are using the GTK+ library so that we can care as little as possible about OS specific things. Your point about inconsistent file choosers is still valid but I don't really see a trivial solution. Keep in mind that GIMP's usage of the file chooser is more involving than just firing up a dialog to get a file path. It would not be feasible to maintain the code that interacts with the file chooser for multiple file choosers, at least not with the current GIMP developer resources.

BR, Martin

I understand why it is the way it is, which is why I mention that it is sometimes the 'right' decision. However, end users don't like it, no matter what the technical merits may be. Also, each application obviously has it's own special needs, and the OS default File Chooser cannot satisfy them all.

I understand why it is the way it is, which is why I mention that it is sometimes the 'right' decision. However, end users don't like it, no matter what the technical merits may be. Also, each application obviously has it's own special needs, and the OS default File Chooser cannot satisfy them all.

Maybe the GTK library (GtkFileChooser, to be specific) could show the native Windows dialog, if available?

One standardised file chooser can't satify all needs, but a solution is that there are hooks and other mechanisms that allow applications to extend the file chooser.

However this should be discussed in a GTK forum/mailing list.

Hi,

On Sun, 2009-01-04 at 00:17 +0100, Heinrich Moser wrote:

Sven Neumann writes:

On Sat, 2009-01-03 at 17:35 +0100, Heinrich Moser wrote:

Is it possible to make GIMP use the "default" Windows File Open/Save dialog*, for example, by setting some secret configuration option?

No. And we are certainly not willing to add such an option.

OK, thanks for the information. In that case, I can just hope that such a plug-in turns up again somewhere.

You can easily write such a plug-in yourself, in case there's really no way to locate the old one. It should be a trivial plug-in to write for someone who knows the Windows file-chooser API.

You should report this as a bug against GTK+ then and perhaps you will also want to help the GTK+ developers to isolate and fix the cause for this.

Thanks for the pointer into the direction of GTK. To verify this, I've just downloaded gedit. It seems to use the same file open dialog library (except for the preview), but, surprisingly, it is indeed faster than GIMP (~10 seconds to show the directory contents, as compared to ~30 with GIMP).

You should investigate this then. It seems rather unlikely that GIMP is doing something with the file-chooser that could be responsible for this. What GTK+ version are you using with GIMP and which with gedit?

Sven

I wonder if a problem I have had with saving files from Gimp in Windows is somehow related. If I save direct to the local hard drive, there isn't much of a problem. But if I try to save to say, a flash drive plugged into the same computer running Gimp, or to a network drive, then file save times get really long. Yes, you expect those two situations to take a bit longer, but not that long. I can save an .xcf file to the local drive and then transfer it to a flash drive or a network drive and it is loads faster than trying to save directly from Gimp. (which is what I typically do, save first to the local hard drive, then transfer the file to the drive I actually want to store the file on.)

--- On Sat, 1/3/09, Sven Neumann wrote:

From: Sven Neumann
Subject: Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog To: "Heinrich Moser"
Cc: gimp-user@lists.xcf.berkeley.edu Date: Saturday, January 3, 2009, 6:44 PM Hi,

On Sun, 2009-01-04 at 00:17 +0100, Heinrich Moser wrote:

Sven Neumann writes:

On Sat, 2009-01-03 at 17:35 +0100, Heinrich Moser

wrote:

Is it possible to make GIMP use the

"default" Windows File Open/Save

dialog*, for example, by setting some secret

configuration option?

No. And we are certainly not willing to add such

an option.

OK, thanks for the information. In that case, I can

just hope that

such a plug-in turns up again somewhere.

You can easily write such a plug-in yourself, in case there's really no
way to locate the old one. It should be a trivial plug-in to write for
someone who knows the Windows file-chooser API.

You should report this as a bug against GTK+ then

and perhaps you will

also want to help the GTK+ developers to isolate

and fix the cause for

this.

Thanks for the pointer into the direction of GTK. To

verify this, I've

just downloaded gedit. It seems to use the same file

open dialog

library (except for the preview), but, surprisingly,

it is indeed

faster than GIMP (~10 seconds to show the directory

contents, as

compared to ~30 with GIMP).

You should investigate this then. It seems rather unlikely that GIMP is
doing something with the file-chooser that could be responsible for
this. What GTK+ version are you using with GIMP and which with gedit?

Sven

Hi,

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.

Sven

Hi,

On Sat, 2009-01-03 at 18:16 -0800, Elwin Estle wrote:

I wonder if a problem I have had with saving files from Gimp in Windows is somehow related. If I save direct to the local hard drive, there isn't much of a problem. But if I try to save to say, a flash drive plugged into the same computer running Gimp, or to a network drive, then file save times get really long. Yes, you expect those two situations to take a bit longer, but not that long. I can save an .xcf file to the local drive and then transfer it to a flash drive or a network drive and it is loads faster than trying to save directly from Gimp. (which is what I typically do, save first to the local hard drive, then transfer the file to the drive I actually want to store the file on.)

No, that is because your operating system of choice sucks at file I/O. Windows does not buffer access to flash and network drives. So an application writing a file with lots of file I/O calls will get miserable performance for slow drives. Copying the complete file to that drive will transfer the data in much larger blocks and thus yield reasonable performance. This is not the case on Linux for example. There the operating system will take care of combining many small file I/O operations into large buffer accesses.

We might be able to work around this limitation by porting the XCF load and save routines and all file plug-ins to GIO, the VFS API that was recently added to GLib. Then we could use a GBufferedOutputStream which would do the buffering at the application level.

Sven

On Wed, 07 Jan 2009 22:11:37 +0100, Sven Neumann wrote:

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.

I personally find the GTK+ widget so bad compared to the native Windows one that I usually resort to dragging images from Explorer when I want them opened in GIMP (and I don't use Explorer for file management, but my usual file manager works in console and thus doesn't support drag and drop).

On Wed, 07 Jan 2009 22:19:03 +0100, Sven Neumann wrote:

No, that is because your operating system of choice sucks at file I/O. Windows does not buffer access to flash and network drives.

It does this with removable drives because users rarely bother to eject (unmount) them before unplugging them. You can enable caching (which greatly improves performance), but then you have to remember to eject the device before disconnecting it, or you risk filesystem corruption.

2009/1/7 Jernej Simon?i? :

On Wed, 07 Jan 2009 22:19:03 +0100, Sven Neumann wrote:

No, that is because your operating system of choice sucks at file I/O. Windows does not buffer access to flash and network drives.

It does this with removable drives because users rarely bother to eject (unmount) them before unplugging them. You can enable caching (which greatly improves performance), but then you have to remember to eject the device before disconnecting it, or you risk filesystem corruption.

No, users rarely bother to eject (unmount) them before unplugging them because the OS works like this. If the OS said "bad boy!" and lost data _once_ then the users would stop. This is a case of the OS fostering bad habits by treating the users as idiots who are unable to learn something so simple as pressing an eject button before physically removing hardware.

Thanks for the information...BTW, Windoze isn't my OS of choice. I sometimes use Gimp at work, where we are pretty much stuck with Windows (Unless I want to go to the trouble of booting a Linux live CD). At home I have Linux and Mac OSX (Gimp runs kinda funky on OSX...but since I have Linux, I don't worry about it too much.)

--- On Wed, 1/7/09, Sven Neumann wrote:

From: Sven Neumann
Subject: Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog To: chrysalis_reborn@yahoo.com
Cc: gimp-user@lists.xcf.berkeley.edu Date: Wednesday, January 7, 2009, 4:19 PM Hi,

On Sat, 2009-01-03 at 18:16 -0800, Elwin Estle wrote:

I wonder if a problem I have had with saving files

from Gimp in

Windows is somehow related. If I save direct to the

local hard drive,

there isn't much of a problem. But if I try to

save to say, a flash

drive plugged into the same computer running Gimp, or

to a network

drive, then file save times get really long. Yes, you

expect those

two situations to take a bit longer, but not that

long. I can save

an .xcf file to the local drive and then transfer it

to a flash drive

or a network drive and it is loads faster than trying

to save directly

from Gimp. (which is what I typically do, save first

to the local hard

drive, then transfer the file to the drive I actually

want to store

the file on.)

No, that is because your operating system of choice sucks at file I/O.
Windows does not buffer access to flash and network drives. So an
application writing a file with lots of file I/O calls will get
miserable performance for slow drives. Copying the complete file to that
drive will transfer the data in much larger blocks and thus yield
reasonable performance. This is not the case on Linux for example. There
the operating system will take care of combining many small file I/O
operations into large buffer accesses.

We might be able to work around this limitation by porting the XCF load
and save routines and all file plug-ins to GIO, the VFS API that was
recently added to GLib. Then we could use a GBufferedOutputStream which
would do the buffering at the application level.

Sven

I eject mine every time. Gimp is the only program that has this problem. I use Inkscape with it and it works fine.

--- On Wed, 1/7/09, Dotan Cohen wrote:

From: Dotan Cohen
Subject: Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog To: "Jernej Simon?i?"
Cc: gimp-user@lists.xcf.berkeley.edu Date: Wednesday, January 7, 2009, 6:11 PM 2009/1/7 Jernej Simon?i? :

On Wed, 07 Jan 2009 22:19:03 +0100, Sven Neumann

wrote:

No, that is because your operating system of

choice sucks at file I/O.

Windows does not buffer access to flash and

network drives.

It does this with removable drives because users

rarely bother to eject

(unmount) them before unplugging them. You can enable

caching (which

greatly improves performance), but then you have to

remember to eject the

device before disconnecting it, or you risk filesystem

corruption.

No, users rarely bother to eject (unmount) them before unplugging them
because the OS works like this. If the OS said "bad boy!" and lost
data _once_ then the users would stop. This is a case of the OS
fostering bad habits by treating the users as idiots who are unable to
learn something so simple as pressing an eject button before
physically removing hardware.

2009/1/8 Elwin Estle :

I eject mine every time. Gimp is the only program that has this problem. I use Inkscape with it and it works fine.

The problem is not that any particular user (you) does not eject disks properly. The problem is that the OS is designed to have disks ejected improperly.

On Thu, 8 Jan 2009 01:11:48 +0200, Dotan Cohen wrote:

No, users rarely bother to eject (unmount) them before unplugging them because the OS works like this. If the OS said "bad boy!" and lost data _once_ then the users would stop.

Windows 2000 did that. Users were not happy.

On Thu, 8 Jan 2009 13:15:47 +0100, Jernej Simon?i? wrote:

On Thu, 8 Jan 2009 01:11:48 +0200, Dotan Cohen wrote:

No, users rarely bother to eject (unmount) them before unplugging them because the OS works like this. If the OS said "bad boy!" and lost data _once_ then the users would stop.

Windows 2000 did that. Users were not happy.

Also, why should the user have to dismount the volume at all? Why would he need to care about such things?

On Sat, Jan 3, 2009 at 11:35 PM, Heinrich Moser wrote:

Hi!

Short question:

Is it possible to make GIMP use the "default" Windows File Open/Save dialog*, for example, by setting some secret configuration option? I remember that there was a plug-in for this a long time ago (which added "Windows Open" and "Windows Save As" menu options) but I cannot find that anymore.

The FileOpen plugin can be found here

http://asso.lsf.05.free.fr/telechargement/image/gimp/?M=A

I tried it with GIMP 2.6.4, it worked but we need to create a new image first before the menu become active, otherwise the menu is disabled. Also the file open dialog appeared behind the image window.

Hi,

On Fri, 2009-01-09 at 08:14 +0700, Charles wrote:

The FileOpen plugin can be found here

http://asso.lsf.05.free.fr/telechargement/image/gimp/?M=A

I tried it with GIMP 2.6.4, it worked but we need to create a new image first before the menu become active, otherwise the menu is disabled. Also the file open dialog appeared behind the image window.

At least the first issue can easily be addressed. The plug-in should use the empty string as "image-type" parameter in the procedure registration. It probably uses "*" which means "activate this plug-in if there's an image, no matter what image type".

Sven