On 2/10/06, Scott wrote:

I don't know where else to vent other than this list, so forgive if inappropriate.

This is gtk-related, not GIMP related, actually. It was discussed here at least one time, which resulted in a flame war of a universe scale :)

Please use Ctrl+L in Open/Save dialog to type in path

Alexandre

On Fri, Feb 10, 2006 at 02:06:52PM -0700, Scott wrote:

IMHO, any app which is asking for a filename as input should give both a keyboard-oriented and a mouse-oriented means of providing it. How much extra work is that to program? *Especially* when it has already been done, and done well, in previous versions??!

well, welcome to the free world. i suspect that you have to buy this functionality from novell.

please write to federico@novell.com and get the price list from them for this functionality and post it here.

carol

Scott wrote:

Sorry, I seem to have unwittingly stepped into some hornet's nest.

Yes, you certainly did. :-) Some bright GTK+ developer decided to make some changes to the dialog box sometime ago leading to the current situation. To avoid rehashing this issue here you should look at the outstanding bug report about this in Bugzilla. Its bug number 136541 (http://bugzilla.gnome.org/show_bug.cgi?id=136541).

Hi,

Scott wrote:

Sorry, I seem to have unwittingly stepped into some hornet's nest. Novell? I have no idea what is meant. I'm just an ignorant user who used to like the way gimp worked, I have no clue what Novell would have to do with it now not working. It must be an inside joke.

This issue has cause a *huge* amount of bad-feeling and in-fighting in the past, so rather than dig it all up again, I'll just offer the two workarounds I use.

Firstly, I generally have GQView running behind the GIMP and use its internal image browser to locate files. I just drag-n-drop them into the GIMP's window. (You really need a window manager that will allow you to disable click-to-front for this to work well, though - i.e. not Metacity, unless you're up to patching it. That's another issue that's caused similar rows.)

The other trick I use is to set up an alias to gimp-remote in my shell, so if I want to open a file that's quicker to type than locate, I just type: gr /path/to/file
That way I can use the shell's tab completion.

Ironic, isn't it, that a UI simplification intended to make newbies more comfortable results in me resorting to the shell...

All the best, --
Alastair M. Robinson

On 2/13/06, Scott wrote:

On Sat, Feb 11, 2006 at 01:25:21AM +0000, Alastair M. Robinson wrote:

Ironic, isn't it, that a UI simplification intended to make newbies more comfortable results in me resorting to the shell...

I wonder; are we witnessing the coming-of-age of a new generation of programmers who grew up *not* using the shell, and who therefore overlook the importance of shell-like features in the GUI?

It would be ironic if that were the case.

Rockwalrus

Hi,

Scott wrote:

That is a good idea. I usually use gqview to find the 1st file I want to edit, then Ctrl-1 - being very unmousy, I never thought to drag-n-drop. I'm using fluxbox, so I'm sure I can get it set up to work for me. Thanks! And for the gr tip too.

In that case, then, you'd do well to change the external editor command in GQView from "gimp %f" to "gimp-remote %f" - then the files will open in an existing GIMP instance if there is one, and you can continue to avoid the mouse :)

All the best, --
Alastair M. Robinson

Hi,

Scott writes:

Haven't had time to extensively check out the newest version, and I'm sure it has a lot of nifty new features: BUT one think that irks me right away is not having any option to type in a filename on the 'open' dialogue!

There is nothing that keeps you from typing a filename in the file open dialog. Perhaps you should just give it a try one day. But, and I think this has already been pointed out, this is something that you should sort out with the GTK+ developers.

Sven

On Tuesday 14 February 2006 06:00 am, Sven Neumann wrote:

Hi,

Scott writes:

Haven't had time to extensively check out the newest version, and I'm sure it has a lot of nifty new features: BUT one think that irks me right away is not having any option to type in a filename on the 'open' dialogue!

There is nothing that keeps you from typing a filename in the file open dialog. Perhaps you should just give it a try one day. But, and I think this has already been pointed out, this is something that you should sort out with the GTK+ developers.

Unless, of course, the filename is in the ~/.gimp-2.x dir and you try to getthere by start typing "."

I am serious about this: I _lost_ almost 20 minutes in a 3 hour workshop trying to get people to open files in ~/.gimp-2.x - and after that I still had to try to explain why ctrl+l + ".gimp-2.2" + would work, and ".gimp-2.2" + , although displaying something would do nothing.
Most people windows users for the first time using a GNU/Linux desktop. I guess they won't come be coming back any soon now.

I think it is quite clear by now that this lack of a visible place to type a filename is damaging to both all of gnome, the Gimp, and in situations like the above, to the whole Free Software movement. The current "transparent type" hack simply does not work as it should - if it should at all.

Regards,
Joao

Sven

Joao S. O. Bueno Calligaris writes:

Unless, of course, the filename is in the ~/.gimp-2.x dir and you try to getthere by start typing "."

I am serious about this: I _lost_ almost 20 minutes in a 3 hour workshop trying to get people to open files in ~/.gimp-2.x - and

It really is fairly tricky with the new file selector to explain to people how to get to files in ~/.gimp (for instance, to save or manage custom brushes, gradients etc.)

I know this isn't the place to flame about the gtk file selector and save-as dialogs ... but given that GIMP does use the new dialogs now, and that there are sometimes valid reasons to need to open or save images inside the GIMP profile, has there been any thought on adding a gimp-specific button in GIMP's version of the dialogs which would take the user directly to the user's GIMP profile? That is possible with the current dialogs, isn't it?

It would make life so much easier for newbies who aren't entirely clear on the concept of a file system (and believe me, there are a lot of people interested in editing images who have no idea whether they have a "home directory" or how to manage subfolders, let alone hidden directories), as well as for the people who are trying to teach them how to use gimp.

The advantage over a bookmark (besides not needing to figure out how to navigate there the first time) is that most people don't edit images inside their gimp profiles often enough to make it worth adding a bookmark that will then show up in every other gtk app they use.

...Akkana

Hi,

Akkana Peck writes:

It really is fairly tricky with the new file selector to explain to people how to get to files in ~/.gimp (for instance, to save or manage custom brushes, gradients etc.)

Perhaps the question that we should ask ourselves is, why do we require users to work with files in hidden directories? I think this is the actual problem here. The user should never ever have to do this. We need to either move some of our resource files into a visible folder or we need to provide a user interface to manage resource files that doesn't involve using a file manager.

I know this isn't the place to flame about the gtk file selector and save-as dialogs ... but given that GIMP does use the new dialogs now, and that there are sometimes valid reasons to need to open or save images inside the GIMP profile, has there been any thought on adding a gimp-specific button in GIMP's version of the dialogs which would take the user directly to the user's GIMP profile? That is possible with the current dialogs, isn't it?

That's a matter of adding this single line of code in the right places:

gtk_file_chooser_add_shortcut_folder (GTK_FILE_CHOOSER (dialog), gimp_directory(), NULL);

We already do this in a few places, like for example the Curves and Levels open and save dialogs.

But I prefer the other solution that I outlined above.

Sven

Hi,

Akkana Peck writes:

It really is fairly tricky with the new file selector to explain to people how to get to files in ~/.gimp (for instance, to save or manage custom brushes, gradients etc.)

While we are on it, could you perhaps try to make a list of use cases where users currently need to access the personal gimp directory? This will help us to make this task easier or to eliminate the need for it.

Sven

On Wednesday 15 February 2006 16:18, Sven Neumann wrote:

The user should never ever have to do this. We need to either move some of our resource files into a visible folder or we need to provide a user interface to manage resource files that doesn't involve using a file manager.

All of which sounds like _much_ more work (and many more design decisions) than simply making the file selector work consistently.

Cheers; Leon

From: Leon Brooks
Date: Wed, 15 Feb 2006 18:28:22 +0800

On Wednesday 15 February 2006 16:18, Sven Neumann wrote: > The user should never ever have to do this. We need to either > move some of our resource files into a visible folder or we > need to provide a user interface to manage resource files that > doesn't involve using a file manager.

All of which sounds like _much_ more work (and many more design decisions) than simply making the file selector work consistently.

Not to mention that someone might want to edit files in a hidden directory for other reasons (e. g. thumbnail files stored in .thumbnails).

On 2/15/06, Robert L Krawitz wrote:

All of which sounds like _much_ more work (and many more design decisions) than simply making the file selector work consistently.

Not to mention that someone might want to edit files in a hidden directory for other reasons (e. g. thumbnail files stored in .thumbnails).

I can hardly imagine a situation when user somehow edits thnumbnails in .thumbnails other than thrashing 'em to free some space on a hard drive :)

But yes, simple way to go to a hidden directory from keyboard should exists, because just typing "~/.something" doesn't work, you have to type a full path.

Don't get me wrong, but I believe that http://bugzilla.gnome.org/show_bug.cgi?id=136541 is more appropriate for further discussion ;)

Alexandre

Von: Alexandre Prokoudine

All of which sounds like _much_ more work (and many more design decisions) than simply making the file selector work consistently.

Not to mention that someone might want to edit files in a hidden directory for other reasons (e. g. thumbnail files stored in .thumbnails).

I can hardly imagine a situation when user somehow edits thnumbnails in .thumbnails other than thrashing 'em to free some space on a hard drive :)

Having access to them can be useful - after all, they are already available, so you could use them to build a thumbnail a gallery. But for this example, it would be more convenient to have this as a script or a "Open thumbnail for this image" entry in the menus.

Accessing hidden directories or moving the location of some from .gimp can get more interesting on other platforms - for example, .gimp on Win32 is not hidden, but hard to get to for the ordinary user (going one directory up from "My Documents" doesn't get you to $HOME).

HTH, Michael

On Wednesday 15 February 2006 10:42 am, Robert L Krawitz wrote:

From: Leon Brooks
Date: Wed, 15 Feb 2006 18:28:22 +0800

On Wednesday 15 February 2006 16:18, Sven Neumann wrote: > The user should never ever have to do this. We need to either > move some of our resource files into a visible folder or we > need to provide a user interface to manage resource files that > doesn't involve using a file manager.

All of which sounds like _much_ more work (and many more design decisions) than simply making the file selector work consistently.

Not to mention that someone might want to edit files in a hidden directory for other reasons (e. g. thumbnail files stored in .thumbnails).

Actually, my problems begun in gedit - I was editing a python script, and certainly, for people on GNU/Linux for the first time, EMACS would not be a suitable option.

GIMPwise, Sven's suggestions are ok. I like more the idea of actually unhiding the gimp profile directory. Because a separate interface to save images that are to be saved as patterns or brushes, IMHO, would only break things even more. A bookmark to the gimp profile would also work. Of the things accessible through other interfaces, I think there is little left to be done.

JS ->

Hi,

"Joao S. O. Bueno Calligaris" writes:

Actually, my problems begun in gedit - I was editing a python script, and certainly, for people on GNU/Linux for the first time, EMACS would not be a suitable option.

emacs is using the GTK+ file chooser as well. At least the later CVS snapshots of emacs are.

GIMPwise, Sven's suggestions are ok. I like more the idea of actually unhiding the gimp profile directory. Because a separate interface to save images that are to be saved as patterns or brushes, IMHO, would only break things even more. A bookmark to the gimp profile would also work. Of the things accessible through other interfaces, I think there is little left to be done.

Could you explain how this would break things? GIMP 2.3 allows you to save the clipboard as brush or pattern, so I am somewhat curious what you consider broken about such an approach.

Sven

On Tue, 2006-02-14 at 18:56 -0800, Akkana Peck wrote:

Joao S. O. Bueno Calligaris writes:

Unless, of course, the filename is in the ~/.gimp-2.x dir and you try to getthere by start typing "."

I am serious about this: I _lost_ almost 20 minutes in a 3 hour workshop trying to get people to open files in ~/.gimp-2.x - and

It really is fairly tricky with the new file selector to explain to people how to get to files in ~/.gimp (for instance, to save or manage custom brushes, gradients etc.)

This is fairly late on the discussion, and hopefully (!) wont dig up the flameware YET AGAIN to the surface, but there's a "Show hidden files" menu entry in the context menu on the file dialog's file list. It works nicely, try it. :-)

Also, personally I like the new file selector _a lot_ more than the old. Drag some bookmarks to the left side, for places you often need to tab-complete into, it really is handy. Yes, it is different from what you were used to. Please try to be open minded.

Most people seem to have a weird idea that "regular users from windows" really want and need to access files in hidden directories with the file selector..

Just because you were used to the old one, does not necessarily mean it is the best interface for everyone. The old one was regarded sucky for a LONG time. We just learned to use it. Do the same for the new, please and lets move on. We can improve the new one once we can leave the past behind :)

//Tuomas

On Fri, 2006-03-24 at 07:48 +0100, Marc Lehmann wrote:

It might be the wrong interface for some or even most users, but it was the most efficient interface for others.

Yep, I agree. The new dialog tab completion could be improved. But in my opinion the new dialog itself is a lot better - the tragedy is in the fact that the most useful feature of the old one suddenly worked a lot worse and on top of it, was hidden and most people just didnt find it.

Yes, the old one was regarded sucky, but not in its entirety. I know you didn't mean offense or anything, but this is a thing many people get annoyed with: the new fileselector removed a very efficient and well-known way of entering paths. Its simply gone. And when they word their concerns about that, they alway sget to hear that they are wrong, that the way they work was bad, and that it simply works. _This_ is IMHO the root of the flames.

You are very correct here.

Its not clear to me wether it can be improved. I personally think the best way would be to have two modes, switchable via some setting. Some people just don't want to use the mouse or wait till the program gets it act together, some simply don't want to switch between tab and another key. They can't get used to that, and its a drawback to them.

Well, if the tab completion was as fast as the older one, we wouldnt have this flamefest of this length.

Even though many people have voiced this very thing, its not people who develop or change things. The only things I hear form those who could change things is that people have to change their way of working, regardless of wether it is more or less efficient for them.

The spark of hope is that there seems to be growing concern and effort into making things more efficient, faster and leaner again in gnome/gtk. Gnome and Gtk has gained a lot of new features over the last years, and undoubtedly accumulated a load of bloat and unoptimized stuff along the road, as often happens in the development cycle. I am happy to see a lot of discussion about this in the community. So we might have hope. :)

No offense taken, no offense intended,

And no need to fear for that, your mail was very insightful. Thanks for the feedback.

//Tuomas

Hi,
tigert@tigert.com (2006-03-26 at 1302.53 +0300):

On Fri, 2006-03-24 at 07:48 +0100, Marc Lehmann wrote:

[...]

Its not clear to me wether it can be improved. I personally think the best way would be to have two modes, switchable via some setting. Some people just don't want to use the mouse or wait till the program gets it act together, some simply don't want to switch between tab and another key. They can't get used to that, and its a drawback to them.

Well, if the tab completion was as fast as the older one, we wouldnt have this flamefest of this length.

Maybe the issue is not the computer speed only, but disturbance in the state of mind? That is my case, when I use tab in shell (or used in old dialogs), I am asking for the help, no surprises. GTK dialogs keep on poping a list and sincerily no idea why I should train myself to ignore things instead of computer stay quiet until asked. And about physical speed, moving hand out of the main block of keys is another issue, mixing mind attention and physical work.

Personally I solved the issue... how? As some others have said, using even more shell. It does tab completion, and even programable in some shells (and disabling it is a handful of keystrokes in bash, C-a, type any char like _ then do whatever you want without filtering, reenable with C-a, C-d). So for open, I use gimp-remote or equivalent, for save, save to somewhere default, then use function that implements "move to cwd". I also get all the tools and tricks you can find in shells, like going to /foo/project1/images/web/ then project2 with a quick edit (and not having to play janitor later with bookmarks), complex globbing or reusing output. It would be indeed nice to get all that help and fast, but only when asked.

GSR
PS: Yeah, guilty of increasing the lenght of another "déjà vu" thread. But at least I hope it becomes clear what cause the issues for some people.