RSS/Atom feed Twitter
Site is read-only, email is disabled

Bring Back the Keyboard!

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

23 of 24 messages available
Toggle history

Please log in to manage your subscriptions.

Bring Back the Keyboard! Scott 10 Feb 22:06
  Bring Back the Keyboard! Alexandre Prokoudine 10 Feb 22:10
  Bring Back the Keyboard! Carol Spears 10 Feb 23:36
   Bring Back the Keyboard! Scott 11 Feb 00:57
    Bring Back the Keyboard! Kevin Cozens 11 Feb 01:49
    Bring Back the Keyboard! Alastair M. Robinson 11 Feb 02:25
     Bring Back the Keyboard! Scott 13 Feb 19:28
      Bring Back the Keyboard! Nathan Summers 13 Feb 20:09
      Bring Back the Keyboard! Alastair M. Robinson 14 Feb 00:18
  Bring Back the Keyboard! Sven Neumann 14 Feb 09:00
   Bring Back the Keyboard! Joao S. O. Bueno Calligaris 15 Feb 03:16
    Bring Back the Keyboard! Akkana Peck 15 Feb 03:56
     Bring Back the Keyboard! Sven Neumann 15 Feb 09:18
      Bring Back the Keyboard! Leon Brooks 15 Feb 11:28
       Bring Back the Keyboard! Robert L Krawitz 15 Feb 13:42
        Bring Back the Keyboard! Alexandre Prokoudine 15 Feb 14:01
        Bring Back the Keyboard! Joao S. O. Bueno Calligaris 16 Feb 02:16
         Bring Back the Keyboard! Sven Neumann 16 Feb 09:01
     Bring Back the Keyboard! Sven Neumann 15 Feb 09:25
     Bring Back the Keyboard! Tuomas Kuosmanen 23 Mar 21:51
Bring Back the Keyboard! Michael Schumacher 15 Feb 16:31
20060324064815.GE6194@schmo... 07 Oct 20:24
  Bring Back the Keyboard! Tuomas Kuosmanen 26 Mar 12:02
   Bring Back the Keyboard! GSR - FR 30 Mar 22:58
Scott
2006-02-10 22:06:52 UTC (about 18 years ago)

Bring Back the Keyboard!

Hello,

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

I have just upgraded to "mandriva 2006", which includes Gimp 2.2 (IIRC - I am writing from my old office machine which has 1.0.4....). I was well-used to 1.2. 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! The tab-completion feature of the older gimps were excellent and very useful. I usually know that the image I want is in, eg "~/web/hvr/webready/raw", and typing that in, especially with tab-completion is *WAY* faster than mousing through some list of dirs. Also, I sometimes want to work on files in a dot-prefixed directory, like .fluxbox/backgrounds. Guess what? They don't show up in the list!

This problem seems to be rampant in other 'new and improved' apps - gdm, for instance. No way to get any .fluxbox/backgrounds in the gtk+ greeter, that's for sure!

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??!

/rant

Scott Swanson

Alexandre Prokoudine
2006-02-10 22:10:32 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Carol Spears
2006-02-10 23:36:19 UTC (about 18 years ago)

Bring Back the Keyboard!

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
2006-02-11 00:57:56 UTC (about 18 years ago)

Bring Back the Keyboard!

On Fri, Feb 10, 2006 at 02:36:19PM -0800, Carol Spears wrote:

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.

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.

I thank Alexandre very much for his suggestion to use Ctrl-L.

And all of you developers for an excellent program. My uncle used to be heavily into graphic design; he was up here for vacation one summer and I was telling him about the gimp. He sort of rolled his eyes at the thought of using anything that was free, but he took a look and soon his eyes were popping out of his head instead.....

Cheers, Scott Swanson

Kevin Cozens
2006-02-11 01:49:24 UTC (about 18 years ago)

Bring Back the Keyboard!

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).

Alastair M. Robinson
2006-02-11 02:25:21 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Scott
2006-02-13 19:28:46 UTC (about 18 years ago)

Bring Back the Keyboard!

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

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.)

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.

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?

Scott Swanson

Nathan Summers
2006-02-13 20:09:43 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Alastair M. Robinson
2006-02-14 00:18:07 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Sven Neumann
2006-02-14 09:00:06 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Joao S. O. Bueno Calligaris
2006-02-15 03:16:00 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Akkana Peck
2006-02-15 03:56:01 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Sven Neumann
2006-02-15 09:18:24 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Sven Neumann
2006-02-15 09:25:32 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Leon Brooks
2006-02-15 11:28:22 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Robert L Krawitz
2006-02-15 13:42:49 UTC (about 18 years ago)

Bring Back the Keyboard!

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).

Alexandre Prokoudine
2006-02-15 14:01:02 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Michael Schumacher
2006-02-15 16:31:03 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Joao S. O. Bueno Calligaris
2006-02-16 02:16:31 UTC (about 18 years ago)

Bring Back the Keyboard!

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 ->

Sven Neumann
2006-02-16 09:01:32 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Tuomas Kuosmanen
2006-03-23 21:51:45 UTC (about 18 years ago)

Bring Back the Keyboard!

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

Tuomas Kuosmanen
2006-03-26 12:02:53 UTC (about 18 years ago)

Bring Back the Keyboard!

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

GSR - FR
2006-03-30 22:58:40 UTC (almost 18 years ago)

Bring Back the Keyboard!

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.