On Fri, May 18, 2012 at 11:33 AM, Ryan Johnson wrote:

3. Use the native "Open file" dialog.

and

Bigger Goal:
Improve the "Open file" dialog to include other viewing modes besides a detail list. It's a graphics program after all! Appeal to the senses!

are mutually exclusive on Windows.

And with the latter request you are telling us to patch the upstream GTK+ dialog.

Alexandre Prokoudine http://libregraphicsworld.org

On 18.05.2012 09:33, Ryan Johnson wrote:

I've been using GIMP to play around with some lighting, color, and GEGL operations on images.
What I've noticed is that the "Open file" dialog is very poorly constructed and it has become a problem. I'm using Win7 x64. Nicely put, it's unintuitive.

These are suggested fixes, and you can choose more than one if it permits.

1. Raise the file size limit for autogeneration of thumbnails.

This is in GIMP's preferences, so a different default would be easy to do,

2. Allow users to multiselect files and explicitly batch-generate thumbnails (just clicking on the thumbnail placeholder with multiple images selected should initiate the process).

this is already possible,

3. Use the native "Open file" dialog.

and no, just no.

Before ever doing that, GIMP should switch to an "if you need better file handling, then use your platform's file manager and open images from there" approach and ditch the file open dialog completely. I wouldn't be surprised if this was a GNOME user interaction goal, either.

I'm using Windows, and I open most file in any program either through their MRU list or via a Windows Explorer window, because all of the file open dialogs are awkward.

Regards, Michael

Am 18.05.12 09:33, schrieb Ryan Johnson:

Hi Ryan,

I checked your complaints with GIMP 2.8 with the following results:

1. Raise the file size limit for autogeneration of thumbnails. Many of my JPEGs are just slightly over 3 MB or whatever the small current limit is. Many of my RAW NEF files are just /under/ 10 MB, at a resolution of 10.2 Megapixels. Many dSLR's exceed my camera's resolution, so my recommended upper limit is 20 MB, but doing a progressive scan (priority queue) would work best. Start out with anything under 5 MB, then 10, then 20 MB, so it is a rough priority queue, instead of a fine-grain one.

There is a solution for you in the preferences dialog. Goto Edit/Preferences/Environment pane. In the middle of the right side you will find the option 'Maximum filesizes for thumbnailing'. That's your friend.

2. Allow users to multiselect files and explicitly batch-generate thumbnails (just clicking on the thumbnail placeholder with multiple images selected should initiate the process).

Have you already tried this? I just did: multiselected files in the list of the 'open file' dialog, clicked on 'Click to create preview' in the right pane - and GIMP just created thumbnails for the selected files. Cool, isn't it? ;-)

Alexandre wrote:

3. Use the native "Open file" dialog.

and

Bigger Goal:
Improve the "Open file" dialog to include other viewing modes besides a detail list. It's a graphics program after all! Appeal to the senses!

are mutually exclusive on Windows.

I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles. Symbols and tiles contain a preview of every file. IIRC it was similar with Windows XP. I think, that's what the OP wants. IMHO using native dialogs has one mantrap: they need to be checked first whether they can fulfill all requirements of the application, like a thumbnail preview. Not every platform may offer all necessary possibilities and keeping track of this could be a hard work. I like the way of the Mac version: there's a 'Show in Finder' menu item in the file dialog, which will start the platforms file manager.

Best regards,

grafxuser

On Fri, May 18, 2012 at 12:59 PM, gfxuser wrote:

I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles.

This is exactly what I was referring to.

There's no need to sit down and create a patch for GTK+ which GTK+ team probably doesn't even want, when you could use native dialogs. Personally I've no special opinion on native vs. GTK+ dialogs on Windows. As a non-Windows user I'm fine with both :)

Alexandre Prokoudine http://libregraphicsworld.org

On 18 May 2012 11:18, Alexandre Prokoudine wrote:

On Fri, May 18, 2012 at 12:59 PM, gfxuser wrote:

I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles.

This is exactly what I was referring to.

There's no need to sit down and create a patch for GTK+ which GTK+ team probably doesn't even want, when you could use native dialogs. Personally I've no special opinion on native vs. GTK+ dialogs on Windows. As a non-Windows user I'm fine with both :)

Please fix GTK+ instead of using some platforms native dialog in GIMP. That way it will work for all GTK+ based applications and on all operating systems supported by GTK+. Remember also that GtkFileChooser is the native dialog for GNOME (and XFCE).

Some work was done recently, but never ended up in mainline. https://bugzilla.gnome.org/show_bug.cgi?id=141154

On 18.05.12 10:59, gfxuser wrote:

I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles. Symbols and tiles contain a preview of every file. IIRC it was similar with Windows XP. I think, that's what the OP wants.

But for XCF files that's not very useful as GIMP doesn't come with an XCF IThumbnailProvider, so all XCF files would only show the Wilber file icon at it's highest resolution instead of a preview... :(

On Fri, May 18, 2012 at 2:19 PM, Kurt Pruenner wrote:

But for XCF files that's not very useful as GIMP doesn't come with an XCF IThumbnailProvider, so all XCF files would only show the Wilber file icon at it's highest resolution instead of a preview... :(

And that's another task for an interested developer.

How about making a publicly available list of platform-specific tasks?

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine wrote:

And that's another task for an interested developer.

How about making a publicly available list of platform-specific tasks?

From my point of view a good idea.

Something to start from: for Mac:
https://bugzilla.gnome.org/buglist.cgi?order=Importance&classification=Other&op_sys=Mac%20OS&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&product=GIMP

for Windows: https://bugzilla.gnome.org/buglist.cgi?order=Importance;classification=Other;op_sys=Windows;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=GIMP

for Linux: https://bugzilla.gnome.org/buglist.cgi?order=Importance;classification=Other;op_sys=Linux;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=GIMP

This can be simply added to the GIMP website or the wiki.

Best regards,

grafxuser (who's not just talking ;-))

On Friday, May 18, 2012, 10:53:46, Michael Schumacher wrote:

3. Use the native "Open file" dialog.

and no, just no.

Err, why? I find the Windows dialog boxes infinitely more usable than GTK+'s (especially after the latest "improvement" with the Recent list).

Before ever doing that, GIMP should switch to an "if you need better file handling, then use your platform's file manager and open images from there" approach and ditch the file open dialog completely. I wouldn't be surprised if this was a GNOME user interaction goal, either.

This certainly sounds plausible, given that I found almost every change to the dialog boxes made them slower and more awkward to use.

I'm using Windows, and I open most file in any program either through their MRU list or via a Windows Explorer window, because all of the file open dialogs are awkward.

I don't - I find the file open dialog much better suited for this (though the bad tab order is slightly annoying in Vista and 7). I almost never use drag-and-drop.

On Fri, May 18, 2012 at 9:01 AM, Jernej Simončič wrote:

Err, why? I find the Windows dialog boxes infinitely more usable than

GTK+'s (especially after the latest "improvement" with the Recent list).

The GTK+ file chooser does seem to be horrible, and I'm not sure why. Here's a usage scenario that continually drives me crazy in GIMP:

1) Create a new image 2) Select File->Save
-> The "Save File" dialog opens
3) Navigate to the correct directory 4) Type the filename to save

Expected result: The highlighted part of "Untitled" in "Name: Untitled.xcf" is replaced with what you type.

Actual result: The dialog assumes you want to destroy a file already in the directory and starts selecting from them until you type something that can't be completed using the files in the directory. Then, another little window appears showing you what you're typing. When you finish typing the name you want to save as and hit Enter, the dialog prompts you to overwrite the file that last matched what you were typing.

I'm not sure if the GTK+ file chooser really is this stupid, or if GIMP isn't setting some kind of "save mode" flag.

Chris

From my perspective, what kind of filepicker dialog an application uses goes a long way in making it look like a native app for its target platform. Allowing the Windows version of GIMP to incorporate the native Win32 filepicker dialog would be a huge improvement at least in platform-specific aesthetics and user convenience -- if nothing else -- but functionally speaking it would also give GIMP the ability to follow Win32 style shortcuts (.lnk files), because that's part of the filepicker functionality. And GIMP would still be able to customize the dialog box with a GIMP-specific thumbnail panel (which, as noted, more frequently skips generating a thumbnail than not) -- that is what you see in current versions of Inkscape's Win32 platform, Inkscape being another GTK+ app.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Date: Fri, 18 May 2012 09:35:32 -0400 From: ccurtis0@gmail.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails

On Fri, May 18, 2012 at 9:01 AM, Jernej Simončič wrote:

Err, why? I find the Windows dialog boxes infinitely more usable than GTK+'s (especially after the latest "improvement" with the Recent

list).

The GTK+ file chooser does seem to be horrible, and I'm not sure why. Here's a usage scenario that continually drives me crazy in GIMP: 1) Create a new image
2) Select File->Save-> The "Save File" dialog opens3) Navigate to the correct directory4) Type the filename to save Expected result: The highlighted part of "Untitled" in "Name: Untitled.xcf" is replaced with what you type.

Actual result: The dialog assumes you want to destroy a file already in the directory and starts selecting from them until you type something that can't be completed using the files in the directory. Then, another little window appears showing you what you're typing. When you finish typing the name you want to save as and hit Enter, the dialog prompts you to overwrite the file that last matched what you were typing.

I'm not sure if the GTK+ file chooser really is this stupid, or if GIMP isn't setting some kind of "save mode" flag. Chris

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

În data de Fri, 18 May 2012 12:25:34 +0400, Alexandre Prokoudine a scris:

are mutually exclusive on Windows.

And with the latter request you are telling us to patch the upstream GTK+ dialog.

The Windows Inkscape version uses Windows native file open and save dialog, so some solution appears to exists already.

Cristi

On 2012-05-18 23:45, Cristian Secară wrote:

The Windows Inkscape version uses Windows native file open and save dialog, so some solution appears to exists already.

It does use it, but that doesn't mean it works. Save as and export bitmap default to empty file names, not the current filename or a variation of it. Also files that have different extensions aren't visible in the view, so you always have to start typing in the filename when you open the export dialog for the first time for a new document as you can't click on the svg file and just change the extension.

These bugs didn't exist when Inkscape used the GTK+ file dialog, and have existed since migrating to the native dialog several years ago. My point is that the way Inkscape uses the Windows native file dialog should not be used as any kind of direction, guide or proof of concept for what could or should be done with GIMP.

În data de Sat, 19 May 2012 00:18:56 +0300, Ville Pätsi a scris:

The Windows Inkscape version uses Windows native file open and save dialog, so some solution appears to exists already.

It does use it, but that doesn't mean it works. Save as and export bitmap default to empty file names, not the current filename or a variation of it.

That's strange. I checked:
- opening Inkscape, either do noting and Save as..., or draw a garbage and Save, will save for me with name "desen" (which probably on an English system is "drawing") and the type drop list default to svg - opening an existing file, Save as... keeps the original name and the type drop list defaults to svg
- exporting the same defaults to \documents_path\name.png

Also files that have different extensions aren't visible in the view, so you always have to start typing in the filename when you open the export dialog for the first time for a new document as you can't click on the svg file and just change the extension.

This is true, the export as bitmap dialog needs some improvement.

These bugs didn't exist when Inkscape used the GTK+ file dialog, and have existed since migrating to the native dialog several years ago. My point is that the way Inkscape uses the Windows native file dialog should not be used as any kind of direction, guide or proof of concept for what could or should be done with GIMP.

Maybe it should not follow exactly, but as direction *this* is the right direction, of course, excluding the limitations.

One thing that I am thinking at is that – for a proper native file dialog – an xcf thumbnail view must be first implemented at OS level (Explorer), not just part of the dialog itself (but I am not sure here).

Anyway, I hope that one day the native GIMP file dialog will be solved somehow. Today I miss the ability to open a file on network, or I was not able to find how.

Cristi

Date: Sat, 19 May 2012 00:18:56 +0300 From: drc@shadowdrama.net
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails

On 2012-05-18 23:45, Cristian Secară wrote:

The Windows Inkscape version uses Windows native file open and save dialog, so some solution appears to exists already.

It does use it, but that doesn't mean it works. Save as and export bitmap default to empty file names, not the current filename or a variation of it.

An application can request what filename is shown in the filepicker's text input field before calling it, so this may or may not be a bug. (If it is, go to the Inkscape bugtracker and report it already!) In Inkscape 0.48.2's case the default filename for the "Save" dialog appears to be "drawing" (the lack of an .svg extension is a moot point because Inkscape can and will append the extension associated with the selected filetype when necessary, which is standard and accepted behavior for pretty much all apps using the native win32 filepicker) and the default filename for the "Export" dialog is "bitmap.png" when exporting an entire page/drawing/custom area, or "(selection_id).png" if exporting selected objects only.

Speaking of this, Inkscape saves the export name with the SVG file so you only have to name an export file once.

Also files that have different extensions aren't visible in the view

Not only is this NOT a bug, but GIMP's filepicker works the exact same way. Ever notice how the default setting for GIMP's filter is "all Images" and not "all Files" ? You will never see, say, .TXT files listed in the Open/Save dialogs unless you specifically select a filter that allows them.

Also of interest, Win32 style shortcuts -- .lnk files -- are always shown in the native dialog whether they match the filetype filter or not, however it is the application's responsibility to tell the filepicker whether it's allowed to follow (dereference) them. Otherwise they get treated like any ordinary file (and, obviously, neither GIMP nor Inkscape can load them).

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

I didn't follow everything that you guys said earlier in this thread (I'm new and still learning terminology related to Gimp), but I'll share some feedback based on my experience with the open file dialogue when using Gimp with Windows:

*1. Auto-show thumbnails. * It would be nice if thumbnails were automatically displayed when looking at files in the open file dialogue so that when you click an image, you see a thumbnail.

Perhaps there's a reason it doesn't happen that way, but either way, I feel way I described is more intuitive.

*2. Ability to paste in a file path without having to click a button (reducing amount of clicks from 2 to 1)* I feel the way file paths are displayed is a bit clunky. It's not easy to convey a better design through text so I won't go into too much depth for now, but I feel it'd be nicer if we could paste in the file path to a folder without having to click to button in the top left corner.

*3. Inconsistency with file open dialogue when you first start Gimp and haven't opened a file*
Something I just noticed was that when you open Gimp (2.8) and try to open a file, the open file dialogue (in Windows) looks different to what it does when you've already opened a file. I.e. When you open Gimp and haven't yet opened a file and try to, the top navigation buttons are absent. This makes it a very not-fun process to navigate to a file you want to open, and there's no place to enter a file path.

This issue goes away once you've opened an image once (even if you close the image and try to open another image). So from what I can tell it seems it's just there for the first image you open.

*Postscript*

I understand what I'm saying may not make much sense if you don't use Gimp with Windows.

On Sun, May 20, 2012 at 2:01 AM, Richard Gitschlag < strata_ranger@hotmail.com> wrote:

Date: Sat, 19 May 2012 00:18:56 +0300 From: drc@shadowdrama.net
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Feature request: Improve the Open file

dialog thumbnails

On 2012-05-18 23:45, Cristian Secară wrote:

The Windows Inkscape version uses Windows native file open and save dialog, so some solution appears to exists already.

It does use it, but that doesn't mean it works. Save as and export bitmap default to empty file names, not the current filename or a variation of it.

An application can request what filename is shown in the filepicker's text input field before calling it, so this may or may not be a bug. (If it is, go to the Inkscape bugtracker and report it already!) In Inkscape 0.48.2's case the default filename for the "Save" dialog appears to be "drawing" (the lack of an .svg extension is a moot point because Inkscape can and will append the extension associated with the selected filetype when necessary, which is standard and accepted behavior for pretty much all apps using the native win32 filepicker) and the default filename for the "Export" dialog is "bitmap.png" when exporting an entire page/drawing/custom area, or "(selection_id).png" if exporting selected objects only.

Speaking of this, Inkscape saves the export name with the SVG file so you only have to name an export file once.

Also files that have different extensions aren't visible in the view

Not only is this NOT a bug, but GIMP's filepicker works the exact same way. Ever notice how the default setting for GIMP's filter is "all Images" and not "all Files" ? You will never see, say, .TXT files listed in the Open/Save dialogs unless you specifically select a filter that allows them.

Also of interest, Win32 style shortcuts -- .lnk files -- are always shown in the native dialog whether they match the filetype filter or not, however it is the application's responsibility to tell the filepicker whether it's allowed to follow (dereference) them. Otherwise they get treated like any ordinary file (and, obviously, neither GIMP nor Inkscape can load them).

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 19.05.2012 19:25, Bruce wrote:

*1. Auto-show thumbnails. *
It would be nice if thumbnails were automatically displayed when looking at files in the open file dialogue so that when you click an image, you see a thumbnail.

This doesn't happen because of bug https://bugzilla.gnome.org/show_bug.cgi?id=669818

With a file size of 1.3GiB reported for every file, you won't get thumbnails automatically because this is way over the configured limit for thumbnails.

*2. Ability to paste in a file path without having to click a button (reducing amount of clicks from 2 to 1)*

You can just paste a path to this dialog (Ctrl+v)

*3. Inconsistency with file open dialogue when you first start Gimp and haven't opened a file*

The dialog starts in the "Recently used" bookmark. That's a special folder, so I guess this is why there are no path buttons to navigate.

HTH, Michael

On 19.05.2012, Michael wrote:

You can just paste a path to this dialog (Ctrl+v)

Indeed. The issue I was describing, however, is that in Windows (not sure about other operating systems) you have to click the "type a file name" button before you can paste in a file name.

Most Windows programs don't require you to click anything before you can paste in a file path (I'm really into designs that require as few clicks as possible when extra clicks aren't really needed), but that aside, the bigger issue is that new Gimp users won't necessarily know to click that button to find the "paste a file path" functionality.

They might learn eventually, but I feel it'd be a nicer experience for them (and experienced users, too) if the "paste in a file path" field was always shown.

I made a mock-up design showing the current open file dialogue for Windows to show what I mean. I'm not sure how well it will show in the email. See if you can click through to view the full-size version:

[image: Inline image 1]

Ultimately I think it'd be nicer to have a drop down file-selector menu at the top that is more like the one in Vista. It lets you click the folders as buttons (like you can now in Gimp), but it's also a drop down menu allowing you to select many more folders (which would be new). I feel it's a fairly quick and intuitive way to navigate through folders.

The dialog starts in the "Recently used" bookmark. That's a special folder,

so I guess this is why there are no path buttons to navigate.

Yeah, I see what you mean.

As above, it'd be nice if it showed the "paste in a file path" field on that first-file-you-open dialogue, even if it did still start with the "Recently used" in focus (which is in the left column of the open file dialogue, if anyone reading this doesn't know what I'm referring to).

* * *

Another issue I just noticed with the open file dialogue (in Windows) is that when I click "Search" under the "Places" list (left column), I get an error:

*Could not start the search process* *The program was not able to create a connection to the indexer daemon. Please make sure it is running. *

Not sure if that's something to do with me and my PC, or Gimp.

On Sun, May 20, 2012 at 3:35 AM, Michael Schumacher wrote:

On 19.05.2012 19:25, Bruce wrote:

*1. Auto-show thumbnails. *

It would be nice if thumbnails were automatically displayed when looking at files in the open file dialogue so that when you click an image, you see a thumbnail.

This doesn't happen because of bug https://bugzilla.gnome.org/** show_bug.cgi?id=669818

With a file size of 1.3GiB reported for every file, you won't get thumbnails automatically because this is way over the configured limit for thumbnails.

*2. Ability to paste in a file path without having to click a button

(reducing amount of clicks from 2 to 1)*

You can just paste a path to this dialog (Ctrl+v)

*3. Inconsistency with file open dialogue when you first start Gimp and

haven't opened a file*

The dialog starts in the "Recently used" bookmark. That's a special folder, so I guess this is why there are no path buttons to navigate.

HTH, Michael

______________________________**_________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/**listinfo/gimp-developer-list

The image I added to the email was scaled down and didn't show much detail.

Here's the full-size version:

[image: Inline image 1]

On Sun, May 20, 2012 at 6:02 AM, Bruce wrote:

On 19.05.2012, Michael wrote:

You can just paste a path to this dialog (Ctrl+v)

Indeed. The issue I was describing, however, is that in Windows (not sure about other operating systems) you have to click the "type a file name" button before you can paste in a file name.

Most Windows programs don't require you to click anything before you can paste in a file path (I'm really into designs that require as few clicks as possible when extra clicks aren't really needed), but that aside, the bigger issue is that new Gimp users won't necessarily know to click that button to find the "paste a file path" functionality.

They might learn eventually, but I feel it'd be a nicer experience for them (and experienced users, too) if the "paste in a file path" field was always shown.

I made a mock-up design showing the current open file dialogue for Windows to show what I mean. I'm not sure how well it will show in the email. See if you can click through to view the full-size version:

[image: Inline image 1]

Ultimately I think it'd be nicer to have a drop down file-selector menu at the top that is more like the one in Vista. It lets you click the folders as buttons (like you can now in Gimp), but it's also a drop down menu allowing you to select many more folders (which would be new). I feel it's a fairly quick and intuitive way to navigate through folders.

The dialog starts in the "Recently used" bookmark. That's a special

folder, so I guess this is why there are no path buttons to navigate.

Yeah, I see what you mean.

As above, it'd be nice if it showed the "paste in a file path" field on that first-file-you-open dialogue, even if it did still start with the "Recently used" in focus (which is in the left column of the open file dialogue, if anyone reading this doesn't know what I'm referring to).

* * *

Another issue I just noticed with the open file dialogue (in Windows) is that when I click "Search" under the "Places" list (left column), I get an error:

*Could not start the search process* *The program was not able to create a connection to the indexer daemon. Please make sure it is running. *

Not sure if that's something to do with me and my PC, or Gimp.

On Sun, May 20, 2012 at 3:35 AM, Michael Schumacher wrote:

On 19.05.2012 19:25, Bruce wrote:

*1. Auto-show thumbnails. *

It would be nice if thumbnails were automatically displayed when looking at files in the open file dialogue so that when you click an image, you see a thumbnail.

This doesn't happen because of bug https://bugzilla.gnome.org/** show_bug.cgi?id=669818

With a file size of 1.3GiB reported for every file, you won't get thumbnails automatically because this is way over the configured limit for thumbnails.

*2. Ability to paste in a file path without having to click a button

(reducing amount of clicks from 2 to 1)*

You can just paste a path to this dialog (Ctrl+v)

*3. Inconsistency with file open dialogue when you first start Gimp and

haven't opened a file*

The dialog starts in the "Recently used" bookmark. That's a special folder, so I guess this is why there are no path buttons to navigate.

HTH, Michael

______________________________**_________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/**listinfo/gimp-developer-list

Please suggest this to the GTK+ developers, so all GTK+ applications have a consistent file dialog. We are not going to implement an own file dialog (which is a project the size of a medium application).

Regards, --mitch

On Sun, 2012-05-20 at 06:12 +1000, Bruce wrote:

The image I added to the email was scaled down and didn't show much detail.

Here's the full-size version:

[image: Inline image 1]

On Sun, May 20, 2012 at 6:02 AM, Bruce wrote:

On 19.05.2012, Michael wrote:

You can just paste a path to this dialog (Ctrl+v)

Indeed. The issue I was describing, however, is that in Windows (not sure about other operating systems) you have to click the "type a file name" button before you can paste in a file name.

Most Windows programs don't require you to click anything before you can paste in a file path (I'm really into designs that require as few clicks as possible when extra clicks aren't really needed), but that aside, the bigger issue is that new Gimp users won't necessarily know to click that button to find the "paste a file path" functionality.

They might learn eventually, but I feel it'd be a nicer experience for them (and experienced users, too) if the "paste in a file path" field was always shown.

I made a mock-up design showing the current open file dialogue for Windows to show what I mean. I'm not sure how well it will show in the email. See if you can click through to view the full-size version:

[image: Inline image 1]

Ultimately I think it'd be nicer to have a drop down file-selector menu at the top that is more like the one in Vista. It lets you click the folders as buttons (like you can now in Gimp), but it's also a drop down menu allowing you to select many more folders (which would be new). I feel it's a fairly quick and intuitive way to navigate through folders.

The dialog starts in the "Recently used" bookmark. That's a special

folder, so I guess this is why there are no path buttons to navigate.

Yeah, I see what you mean.

As above, it'd be nice if it showed the "paste in a file path" field on that first-file-you-open dialogue, even if it did still start with the "Recently used" in focus (which is in the left column of the open file dialogue, if anyone reading this doesn't know what I'm referring to).

* * *

Another issue I just noticed with the open file dialogue (in Windows) is that when I click "Search" under the "Places" list (left column), I get an error:

*Could not start the search process* *The program was not able to create a connection to the indexer daemon. Please make sure it is running. *

Not sure if that's something to do with me and my PC, or Gimp.

On Sun, May 20, 2012 at 3:35 AM, Michael Schumacher wrote:

On 19.05.2012 19:25, Bruce wrote:

*1. Auto-show thumbnails. *

It would be nice if thumbnails were automatically displayed when looking at files in the open file dialogue so that when you click an image, you see a thumbnail.

This doesn't happen because of bug https://bugzilla.gnome.org/** show_bug.cgi?id=669818

With a file size of 1.3GiB reported for every file, you won't get thumbnails automatically because this is way over the configured limit for thumbnails.

*2. Ability to paste in a file path without having to click a button

(reducing amount of clicks from 2 to 1)*

You can just paste a path to this dialog (Ctrl+v)

*3. Inconsistency with file open dialogue when you first start Gimp and

haven't opened a file*

The dialog starts in the "Recently used" bookmark. That's a special folder, so I guess this is why there are no path buttons to navigate.

HTH, Michael

______________________________**_________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/**listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list