On Wed, Jun 22, 2005 at 01:49:40PM +0200, Michael Thaler wrote:

But unfortunately the save as... dialog does not. So everytime I save a rescaled image I have to click on the home directory button and then click until I am in the correct directory. For me it would really be an enhancement if gimp would also remember the directory where pictures are saved with save as. (I know that I can create bookmarks, but I would still prefer that gimp would remember the directory I saved the last image to, because this would save one click).

This covers, exactly, one of my biggest problems with the recent Gimp. (I use 2.2.0 on Windows XP at my work.)

I also find it quite annoying that there is no line edit widget where you can enter the path. In this respect the old gtk file choser widget worked very well (it probably was one of the best) and the new one completely sucks. I really don't understand why the gtk developers removed it. Why is something removed that is apparently useful to a lot of people and is no problem for someone who does not want to use it?

I agree here, as well.

Personally, the new gtk file choser widget is the number one reason I try not to use gtk apps.

Gimp is the _only_ GTK app that I use. The only other non-KDE GUI applications I use on a regular basis (at home on Linux) are Mozilla (but only when I want to use Google Maps, otherwise I use Konqueror) and xview. (Well, there are games, too, but most are SDL-based.)

Another data point: my wife was happily using GNOME 1.2 and when we upgraded here to GNOME 2.0, it only lasted about a day. I asked if she'd like to try KDE, since it seemed to make more sense. She's been using it ever since. (She uses Gimp a lot, as well as Firefox and Gthumb. I'll have to ask what her feelings are on the recent file chooser interface in Gimp.)

Hi,

Michael Thaler writes:

I use gimp occasionally to enhance or rescale photos and I also find it very annoying to work with the new gtk file-selector. Imagine the following situation: I have 20 photos in a directory and want to rescale them and save them to another directory. The open dialog remembers the directory I load the photos from, this is o.k. But unfortunately the save as... dialog does not. So everytime I save a rescaled image I have to click on the home directory button and then click until I am in the correct directory. For me it would really be an enhancement if gimp would also remember the directory where pictures are saved with save as. (I know that I can create bookmarks, but I would still prefer that gimp would remember the directory I saved the last image to, because this would save one click).

That's been requested a couple of times and it would be easy to implement. But I am afraid that it would make one task easier but at the same time introduce problems for other use cases.

Basically what you ask for is not logical. Currently there's exactly one File Open dialog and of course it remembers the folder it was last being used in. There is however a File Save dialog for each image and it comes up with the folder preselected that this image lives in. Now if I open an image from folder A and save it to folder B, why should the file selection dialogs of all other images (whether they are already opened or not) switch to folder B now? There is actually no good reason for such a behaviour and I expect it to cause quite some confusion. But I am open for your view on this...

I also find it quite annoying that there is no line edit widget where you can enter the path. In this respect the old gtk file choser widget worked very well (it probably was one of the best) and the new one completely sucks. I really don't understand why the gtk developers removed it. Why is something removed that is apparently useful to a lot of people and is no problem for someone who does not want to use it?

Because it isn't needed. You can still enter the filename and without the entry it is easier to keep your eye focused on the list while you are doing that. My experience shows that I need less keystrokes to select a file with the new dialog.

Sven

On Thu, 2005-06-23 at 00:24 +0200, Sven Neumann wrote:

Basically what you ask for is not logical. Currently there's exactly one File Open dialog and of course it remembers the folder it was last being used in. There is however a File Save dialog for each image and it comes up with the folder preselected that this image lives in. Now if I open an image from folder A and save it to folder B, why should the file selection dialogs of all other images (whether they are already opened or not) switch to folder B now? There is actually no good reason for such a behaviour and I expect it to cause quite some confusion. But I am open for your view on this...

I agree. Say I'm working in a web design project and the files I would probably put in /home/gezim/projects/web/. So when I go to http://www.sxc.hu/ (great site for royalty free stock images, BTW) find my images, save them to /home/gezim/projects/web/ . Then I would open GIMP open ~/projects/web/flower.jpg manipulate it then guess what? I would save it back in the directory that I opened it from (/home/gezim/projects/web) . If you don't do this, then you're just disorganized and GIMP can't help you with that. When you write something to a harddrive you should (I do anyway) make sure that the location you're putting it in is logical, so it wouldn't need to be changed.

-Gezim

Sven Neumann writes:

Because it isn't needed. You can still enter the filename and without the entry it is easier to keep your eye focused on the list while you are doing that.

I for one find it quite annoying not being able to type full pathnames into the file open dialog, slows me down a lot, is irritating and also limits a lot in that I can't edit the current path with the keyboard, couldn't even figure out how to move a directory up with type-ahead, '..' doesn't work.

The new dialogs is nicly usable with the mouse, but with the keyboard its IMHO *FAR* inferior to the old one, its slow, ugly (neither Ctrl-L window not the type-ahead floating thing feels natural) and simply confusing for really no good reason. Simply adding the text entry widget to the new dialog would almost instantly fix most of the problems it has and from what I can tell would make a lot of users very happy. I really don't get way this still happen, since it was a very common complain from day one, instead we got typeahead which while an improvement doesn't really solve the problems.

My experience shows that I need less keystrokes to select a file with the new dialog.

My experience shows that I need a more, need to grab the mouse and whatever. The new dialog is really not much good for use with the keyboard.

On Thursday 23 June 2005 06:24, Sven Neumann wrote:

Basically what you ask for is not logical.

That's not quite true. It's illogical *from one perspective*; this one:

Currently there's exactly one File Open dialog and of course it remembers the folder it was last being used in. There is however a File Save dialog for each image and it comes up with the folder preselected that this image lives in. Now if I open an image from folder A and save it to folder B, why should the file selection dialogs of all other images (whether they are already opened or not) switch to folder B now?

Because in the minds of many people approaching this, the directory is *not* associated with the _image_, it's associated with the _program_, or to be more specific, to the _job_ or _batch_ that they're working on now. Yes, it breaks the document-centric model a little, but in some situations is it genuinely very useful and time-saving.

The default should be image-centric rather than program-centric (and the help for it should explain why), but it should be simply configurable (click on one widget, not crawl off and run a config program or edit a text file) to be program-oriented, or to be more pedantic, job-centric.

Another way of handling this, which would be more useful but a lot of work, is to introduce the concept of a job or batch - or at least make separate instances of The GIMP behave that way - and invisibly default newly opened images to a common "batch" which stays covert unless the user explicitly creates a new "batch".

This would allow the image-centric motif to be retained, but also cater for the workflow-oriented viewpoint that many users will (rightfully) carry with them to The GIMP.

There is actually no good reason for such a behaviour

You now have one to hand, O thou victim of premature optimisation, and I'm sure I could find more if necessary. (-:

Cheers; Leon

On Thursday 23 June 2005 07:28, Gezim Hoxha wrote:

Say I'm working in a web design project and the files I would probably put in /home/gezim/projects/web/. So when I go to http://www.sxc.hu/ (great site for royalty free stock images, BTW) find my images, save them to /home/gezim/projects/web/ . Then I would open GIMP open ~/projects/web/flower.jpg manipulate it then guess what? I would save it back in the directory that I opened it from (/home/gezim/projects/web). If you don't do this, then you're just disorganized and GIMP can't help you with that.

Disagree. You're just organised in a different way to Sven and Gezim.

When you write something to a harddrive you should (I do anyway) make sure that the location you're putting it in is logical, so it wouldn't need to be changed.

True, but I'm having trouble coming to terms with the idea that your way of organising things is the only one that exists.

I usually work from "unprocessed" into "processed" directories, so does my sister-in-law (who taught herself, so my input isn't a consideration). My wife doesn't, but would if she felt comfortable enough about the rest of the computer (she just about lost it trying to cope with XP's idiosyncrasies a few weeks ago, despite entering that experience believing that "Windows is easier" than what she was using (KDE)) _or_ if The GIMP made it easier.

To really underscore the "I am not a voice in the wilderness" point, I also watched over the shoulder of two different people GIMPing stuff at LCA2005, and they both worked the same way (one of them grumbled about it at the time, less after I pointed out that he could make and dispose of "bookmarks" on the fly).

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

Hi,

Leon Brooks writes:

I usually work from "unprocessed" into "processed" directories, so does my sister-in-law (who taught herself, so my input isn't a consideration). My wife doesn't, but would if she felt comfortable enough about the rest of the computer (she just about lost it trying to cope with XP's idiosyncrasies a few weeks ago, despite entering that experience believing that "Windows is easier" than what she was using (KDE)) _or_ if The GIMP made it easier.

To really underscore the "I am not a voice in the wilderness" point, I also watched over the shoulder of two different people GIMPing stuff at LCA2005, and they both worked the same way (one of them grumbled about it at the time, less after I pointed out that he could make and dispose of "bookmarks" on the fly).

Bookmarks do indeed work very well for this but they are obviously not the ideal solution.

I don't really see how we could possible improve this. If I open the Save As dialog on an image that already has a filename, then I definitely expect the file-chooser to come up with this filename preselected. Everything else would, IMO, be a major source of confusion.

Sven

Hi,

Ingo Ruhnke writes:

couldn't even figure out how to move a directory up with type-ahead, '..' doesn't work.

Alt-Up brings you up one level in the folder hierarchy.

My experience shows that I need a more, need to grab the mouse and whatever. The new dialog is really not much good for use with the keyboard.

I can only state once more that I rarely ever use the mouse in that dialog. I use the mouse to change a file filter and I use it to manipulate bookmarks, certainly not for navigating the file list. I accept that it doesn't work for you but it is wrong to state that the new dialog is not much good for use with the keyboard.

Sven

On Thursday 23 June 2005 16:40, Sven Neumann wrote:

Leon Brooks writes:

I usually work from "unprocessed" into "processed" directories, so does my sister-in-law (who taught herself, so my input isn't a consideration). My wife doesn't, but would if she felt comfortable enough about the rest of the computer (she just about lost it trying to cope with XP's idiosyncrasies a few weeks ago, despite entering that experience believing that "Windows is easier" than what she was using (KDE)) _or_ if The GIMP made it easier.

To really underscore the "I am not a voice in the wilderness" point, I also watched over the shoulder of two different people GIMPing stuff at LCA2005, and they both worked the same way (one of them grumbled about it at the time, less after I pointed out that he could make and dispose of "bookmarks" on the fly).

Bookmarks do indeed work very well for this but they are obviously not the ideal solution.

Agree.

I don't really see how we could possible improve this.

[ ] Default to last-used instead of source directory

Note that the default-default is still to *not* do this. And while we're at it:

[ ] Default to expanded file dialog(ue)s

If I open the Save As dialog on an image that already has a filename, then I definitely expect the file-chooser to come up with this filename preselected.

Yes. I think we all understand that.

Everything else would, IMO, be a major source of confusion.

Yes, that's absolutely correct in every detail.

What I'm trying to achieve here is to put across some evidence is that Sven's good, honest, valid and valuable opinion isn't the same as everyone else's opinion - more, that "everyone else" includes a large number of people are are confused by an approach which is native, i'm natural and appropriate for Sven.

I apologise if this comes across to you as pedantic, simplistic, condescending etc, but I can't think of an easy way to get the point across: Sven's view of the situation, excellent and obviously useful though it is, is not the only functional or useful view of the world.

Here's how I see it: you are thinking in terms of the location being essentially just another property of the image, and the file dialog(ue)s being expressions of that property. Others are looking at the image as being an object within the filesystem, conceptually detached from its internal properties.

Detaching the location property confuses you. Integrating it confuses others. I believe that we can and should cater for the second mindset without substantially disturbing the first.

I look forward to someone else finding a third (or forth) common workflow and a way to incorporate them all into a GTK file dialog. (-:

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

On Thu, Jun 23, 2005 at 12:24:24AM +0200, Sven Neumann wrote:

developers removed it. Why is something removed that is apparently useful to a lot of people and is no problem for someone who does not want to use it?

Because it isn't needed. You can still enter the filename and without the entry it is easier to keep your eye focused on the list while you are doing that. My experience shows that I need less keystrokes to select a file with the new dialog.

How are we to interpret that? You use more keystrokes because there is an additional widget on the screen? Or is this just the general "the new dialogs are good, just believe me" slogna?

On Thursday 23 June 2005 17:15, Leon Brooks wrote:

I look forward to someone else finding a third (or forth) common workflow and a way to incorporate them all into a GTK file dialog. (-:

Should add in the existing dialogue's defence (if it needs one) that I was delighted today to discover that multiple selections are active and Do The Right Thing, ie, open images from multiple files. A small thing, but inordinately pleasing.

Cheers; Leon

Sven Neumann writes:

couldn't even figure out how to move a directory up with type-ahead, '..' doesn't work.

Alt-Up brings you up one level in the folder hierarchy.

This brings me only up one level in the presented folder hierachy, not one level up in the directory hierachy. So if I am in [Home] or [Desktop] or other 'special' locations I can't go further, even so there still would be a directory. So is it right that I have to either use the mouse or restart from / if I one to go higher than that?

I can only state once more that I rarely ever use the mouse in that dialog. I use the mouse to change a file filter and I use it to manipulate bookmarks, certainly not for navigating the file list. I accept that it doesn't work for you but it is wrong to state that the new dialog is not much good for use with the keyboard.

Well, it might still be keyboard navigatable to some degree (support for '..' and such whould be nice), but I fail to see how it should be in any way superior to the old one whe used with the keyboard.

So here's a half baked proposal. Make of it what you will. I am beginning to see why it is quite complicated.

The current file chooser stays the same by default, except that a label is added somewhere that reads "Type a filename" or whatever (to give some kind of visual cue that you can type a filename to it). This isn't essential to my proposal, but I think that the cue should be there in any case.

Also by default, starting to type a filename pops up a filename entry, as currently done. However, there's one additional little checkbox named "Dock With Chooser" or the like. If this is checked, the filename entry (and checkbox) immediately integrates with the chooser, and stays there until/unless Dock With Chooser is unchecked. This state is saved, so the next time the chooser pops up it's in the same state as it last was.

Therefore, if Dock With Chooser is not checked, everything behaves exactly as it does now. If it is checked, the main dialog has a tab completing pathname entry box.

What happens when Dock With Chooser is selected? Let's start with some definitions:

* A "filename" refers to the base name component of a path (i. e. what "basename" returns).

* A "dirname" refers to the directory component of a path (i. e. what "dirname" returns, with a path component separator appended).

* A "pathname" refers to the concatenation of a (possibly empty) directory name with a (possibly empty) filename

The "focus" (or whatever it's called in this situation -- it's not the window receiving focus, but rather the active widget) is the same as usual, but if you start typing, focus is switched to the text entry box. The entry box starts with an empty pathname.

Next, some definitions:

How does tab work? Here are the cases:

1) If the entry box contains an empty pathname, tab always goes to the next widget.

2) If the most recent action was switching into the entry box, tab simply switches to the next widget.

3) If the most recent action was typing something into the entry box, tab attempts to complete as much as it can. The next tab switches to the next widget (i. e. two tabs in a row switches out).

Alternatively, tab only completes as far as a single directory name. Typing tab again completes as much as it can within the next directory, and then the next tab switches out.

I was also thinking that the normal tab order should simply skip the entry box, so the only ways to use the entry box are to either click in it with the mouse or start typing. That's also an alternative.

(Have I missed anything?)

A few more things:

1) If the dirname in the entry box is empty, any filename is interpreted relative to the otherwise selected directory.

2) If the dirname in the entry box is not empty, the directory of the entire file chooser is dynamically set to the dirname of the entry box (e. g. as a path component is typed or erased, the directory of the file chooser changes on the fly).

3) Selecting another directory with any other widget replaces any directory component typed into the chooser, but leaves the file component intact. Thus, if I've typed /foo/bar.j into the browser, and then select /home/rlk, "/foo/" is erased from the entry widget, leaving "/foo/bar.j".

4) Selecting a filename with other widgets in the chooser erases any filename in the widget, and replaces it component with the filename selected. Thus, if I've typed /foo/bar.j into the entry box, the directory of the entire chooser has been changed to /foo. If I now select "baz.jpg" via any other means, the entry box receives the text "/foo/baz.jpg".

No doubt I've missed some things, but this is a starting point.

Hi,

Leon Brooks writes:

[ ] Default to last-used instead of source directory

Does it really make sense to make this a preference option? Wouldn't it be better to add a UI that deals explicitely with processing batches of images? Adding this as a gimprc parameter would probably be easy but it seems like a quick and dirty solution. We have the chance to get this right for 2.4, so let's see if we can't find a better solution...

Sven's view of the situation, excellent and obviously useful though it is, is not the only functional or useful view of the world.

Heh, needless to tell me. But it is probably good that you mention that since obviously a few people missed that point.

Sven

On Friday 24 June 2005 08:41, Sven Neumann wrote:

Does it really make sense to make this a preference option?

Really only if you also have a toggle or two on the widget itself to allow it to be changed on the fly. Or at least a gimprc-configurable option to _present_ such toggles in the widget.

Wouldn't it be better to add a UI that deals explicitely with processing batches of images?

No, for many reasons. Although this raises a couple of other possibilities.

Another toggle which says "open these one at a time", ie, "when the first image is closed, automatically open the second, etc", would be separately useful.

A special batch-processing UI would have its own independent uses, (e.g. it would be handy to be able throw a macro at a batch of Gnumeric files in one go), but does not directly address the issue.

We're not trying to turn The GIMP into a GUI copy of ImageMagick. The purpose of the exercise is to cater straightforwardly to the batching _mindset_ rather than a specifically batched situation.

The object is to be able to face a directory of "raw" images, select some of them to work on _in_different_ways_ and be able to save the results to a different directory without having to steer the file-save dialog to the output directory afresh for every single file.

Solving it witgh a purpose-built batch UI would provide a more complicated arrangement (separate Open function) which is of limited use (but see above for an exception) outside GIMPland and would be quite confusing to handle in applications with no dialect of MDI or real concept of document-centricity.

We have the chance to get this right for 2.4, so let's see if we can't find a better solution...

I hope so. An elegant UI is a fine objective, but putting theory in front of practicality is generally a bad idea. The practicality here is that neither the old UI nor the present one is intuitive for all comers, and for different reasons. The ideal outcome would be a widget at least as simple as the existing one, but which you can use a rc or similar mechanism to complicate if it suited your manner of working.

One specific oft-requested complication is a sticky save directory.

Cheers; Leon

Von: Sven Neumann

Leon Brooks writes:

[ ] Default to last-used instead of source directory

Does it really make sense to make this a preference option? Wouldn't it be better to add a UI that deals explicitely with processing batches of images? Adding this as a gimprc parameter would probably be easy but it seems like a quick and dirty solution. We have the chance to get this right for 2.4, so let's see if we can't find a better solution...

I'd like to see the bookmarks system being used for this. Maybe in this fashion:

- have a special bookmark that specifies "last used directory" - have a way to set one bookmark as the default bookmark

If any of this is already possible, I'm currently not aware of it.

This way, whenever the 'Save as' dialog comes up, the last used directory could be selected. If you don't want this, choose another default; or none and the current behaviour will be used.

Of course, this is something that will have to be suggested to GTK+, but since we have so many people here who claim that they know why the fileselector is bad or good, I'd like to have my suggestions examined here first :)

Michael

Hi,

Robert L Krawitz writes:

Also by default, starting to type a filename pops up a filename entry, as currently done.

But typing a filename does not currently pop up a filename entry. There are corner cases where it does (absolute paths) but in general there is no such popup and there shouldn't be one.

Sven

Hi,

Leon Brooks writes:

A special batch-processing UI would have its own independent uses, (e.g. it would be handy to be able throw a macro at a batch of Gnumeric files in one go), but does not directly address the issue.

We're not trying to turn The GIMP into a GUI copy of ImageMagick. The purpose of the exercise is to cater straightforwardly to the batching _mindset_ rather than a specifically batched situation.

Such a UI has been requested quite frequently and I think it would be very nice to be able to mark a directory or a bunch of images for batch processing. The list of selected images could be shown in a dockable (perhaps even the already existing Images dialog) and you could work your way through this list. In such a context, it would make a lot of sense to remember the save location and default to the same save directory for all images.

Sven

Hi,

Ingo Ruhnke writes:

Alt-Up brings you up one level in the folder hierarchy.

This brings me only up one level in the presented folder hierachy, not one level up in the directory hierachy. So if I am in [Home] or [Desktop] or other 'special' locations I can't go further, even so there still would be a directory. So is it right that I have to either use the mouse or restart from / if I one to go higher than that?

You can't even use the mouse to go further up from your Home directory since the Home directory (and others like Desktop) are being rerooted. They are basically a root of the directory tree without a parent node. Please note that I haven't claimed that this is a good idea.

Sven

On Fri, Jun 24, 2005 at 09:48:37PM +0200, Sven Neumann wrote:

You can't even use the mouse to go further up from your Home directory since the Home directory (and others like Desktop) are being rerooted. They are basically a root of the directory tree without a parent node. Please note that I haven't claimed that this is a good idea.

Windows (most native apps, that is) does this, as well, with the Desktop concept.

On the one hand, it's helpful because I keep most active projects accessible from my desktop, and can just click the "Up" button numerous times.

In many cases, I can event hit Shift-Tab twice, then hit Space repeatedly to get from {wherever I am by default} to the desktop. Obviously, though, a plain "Desktop" button would make sense, but apparently MS didn't think of that.

However, in SOME cases, once I hit Space once, the "Up" button loses focus, and I'm typing spaces into some other widget. (This seems to happen in 'folder selector' dialogs, which look almost identical to 'file selector' dialogs in Windows.)

Honestly, if I could simply "Up" to the root of the filesystems in Windows, that would be best. Oops, but oh wait, it has this archaic (wait, modern?) concept of drive letters, so I guess above "C:\" I'd need to be taken to "My Computer".

Ugh. Anyway, totally off topic. I'm just letting off steam built up from using WinXP on a daily (work-day, at least) basis ;)