When software violates the basic principles of good programming and user interface design, there will be trouble.
See also the essay "A New Medievalism."
Around 2011, a change was made in GTK+ which made applications which use it completely unusable for serious work. GTK is the toolkit which sits beneath not only the GIMP ("GTK" originally meant Gimp ToolKit) but also a number of major applications. No, I am not exaggerating here. It was not a "feature" so much as a very bad bug (even though it was a deliberate, considered design decision). For anyone trying to use a GTK application such as the GIMP to do serious work (by "serious" I mean in my case using it within a filesystem which has over 4.3 million files), this bug effectively constitutes a denial-of-service attack on you, the user. It makes the GIMP and other GTK applications useless. for anything but playing with toys.
Fortunately, about a year later, the same developer who introduced this bug created a fix for it. This is very good, and very much to the credit of the developer (thank you!) But the fix does require you to create and/or modify a rather obscure configuration file, and the default behavior is still the useless one. Here I'll identify the solution first, and then discuss the problem itself later.
The solution is to alter a line in the configuration file "gtkfilechooser.ini" (or create the file and add the line, if it does not already exist). GTK exists in two simultaneous versions now, 2 and 3. For GTK2, this file is in:
~/.config/gtk-2.0/gtkfilechooser.ini
~/.config/gtk-3.0/gtkfilechooser.ini
In each case the file begins with an identifying line:
[Filechooser Settings]
and continues with several lines which set options for the GTK "file chooser" dialog. To make GTK applications at all usable again, you need to add two lines which say:
LocationMode=filename-entry StartupMode=cwd
Or if these lines currently exist with values such as "LocationMode=path-bar" and "StartupMode=recent", change them.
The first time you use a FileChooser menu (at least), you also need to click on the icon which appears to the left of the path to the cwd. Only then does the FileChooser open up a text entry box where you can (if you wish) enter a different filename by (gasp) typing (instead of climbing through a tree of buttons).
This fixes the problem. Unfortunately, at least in some versions this will also cause the GIMP to begin to spew a huge number of errors to stderr. If this is the case, then you must also dispose of these by adding this to your .bashrc file:
alias gimp='gimp 2> /dev/null'
This disables the whole point of stderr, of course, but that's the price we have to pay to use software today.
Note: GIMP 2.8.10 (at least) seems to behave under Arch Linux (2014-03) and GTK2, and therefore not to need this .bashrc alias.
Note also that there remain other Gnome-world problems that this GTK fix cannot solve. The GIMP 2.8 still breaks all basic rules of sane user interface design with its refusal to let you save files that you opened (we can't fix this). Firefox still tries to save files in bizarre and useless places (we can fix this). But at least it makes the GIMP usable again.
In the fix to this problem, the GTK FileChooser adds the CWD to the list of "Places" on the left (it shows the name of the directory which is the CWD).
In some applications, the GTK FileChooser is called in such a way that this CWD item in "Places" is highlighted when the dialog window opens, displaying your CWD as you expected it to when you set the default behavior of GTK to "cwd". This is as it should be. The GIMP 2.8 as installed on Arch Linux 2014-03 (at least) is an application displaying this behavior.
However, in other applications the GTK FileChooser is called in such a way that some other item in "Places" is highlighted (e.g., "Home"). In this situation, it isn't at all apparent the first time you fire up the application that you can get to the CWD. In these cases, you must remember the name of the directory you're in (no, I don't always) and observe that it is present in the "Places" list/panel. Then click on it. This click (the decision to use the CWD) is remembered for the duration of your session, but is forgotten each time you invoke the program anew. You have to click re-set the CWD behavior actually to be the CWD behavior each time you run the program. Inkscape 0.48 as installed on Arch Linux 2014-03 (at least) is an application displaying this behavior.
(See also the consideration of this problem as symptomatic of a regression of our nominally high-tech society into a new medievalism .)
Since their introduction in the 1960s, the basic set of concepts behind the UNIX operating system has been the primary equipment in the programmer's "mental toolbox." So simple and so powerful are these concepts that serious computer use cannot happen without them. Indeed, to find more basic concepts one has to go back to the very beginning of the computer - Shannon's information theory, Turing's theoretical machine, etc.
One of the most important of these concepts, and the one most visible to the ordinary non-programming computer user, is the hierarchical file system. It is important both because it is a powerful idea in itself and because it mirrors much of the structure of the real world. If you cannot understand and use a hierarchical file system, then you are incapable of understanding the world around you as it has existed since at least the neolithic revolution about 10,000 years ago. It's that basic.
Yet one of the puzzles of computer interface design since the introduction of computers for individual people in the 1980s has been a desperate desire on the part of manufacturers to hide the hierarchical file system. Every computer system sold to individuals after (but not including) MS-DOS 1 has had a hierarchical file system, but all of the commercial manufacturers have decided that it was too hard or too to scary to use and have hidden it. You find this out when you go to help a friend with their mysteriously recalcitrant computer only to find five years' worth of files stuffed into "MyDocuments." It's no wonder they can't find anything.
For a long time, Linux was free of this. Inevitably, though, this way of thinking has infected Linux user interface design. The dream which tempts interface designers now is that they might free the user from ever needing to understand the hierarchical file system on their computer by letting the computer always know (and decide) where to get or put something. The problem, of course, is that the computer can't always know this. Indeed, you don't always know where you want to put something (or at least I don't) until you look around a bit. I'm sure we've all experienced the frustration which results when someone else cleans up your room or workshop and all of a sudden you can't find anything anymore.
In more specific terms, a central concept in any hierarchical structure is the notion of the "current working directory" (CWD). It's where you are in the system. A corollary to this is the notion that where you are defines how you get to the things you want to work on. If you want to use your drill press, for a physical example, you go into your house, walk to the garage, and use your drill (in virtual terms, "cd /home/workshop"). If then you want to use a hammer to knock the broken drill out of your workpiece, you just pick up your hammer from the bench in your workshop. It would be insane to force you to teleport outdoors again, walk back into your house, then walk back into your workshop every single time you wanted to pick up a new tool in your workshop. Yet this is exactly what the developers of GTK want you to do.
In a command-line environment, the CWD is always defined and is easily identifiable (the "pwd" command prints it to your console). If you fire up the GIMP from the command line, having already gone to the location of your image file, your CWD should be defined at startup.
When an application is launched from an icon, its CWD is initially less well defined (in theory it can be undefined, or it can default to some well-known location such as your home directory). But once you actually do anything, the CWD is always defined. You may fire up the GIMP from an icon, and at that point in time its CWD may be undefined, or semi-uselessly defined to $HOME. But once you go into some directory and actually open an image file in the GIMP, you have defined a current working directory.
With the 2011 changes to GTK's FileChooser, all this was taken away from the user. In the default GTK behavior, still, it is missing. If in a stock, default installation you go to a particular directory where you have an image file and open up the GIMP from the command line, and then try to open a file in the GIMP, GTK has no clue where you are in the filesystem. It requires you to go back to some standard location and "drill down" through the filesystem to get to the file. This is exactly like forcing someone in their workshop to teleport outside and then walk back into the workshop to pick up a tool - every single time.
What were they thinking? They were thinking that they had figured out a way for the computer to know, beforehand, where you wanted to be. What you get, in the default GTK behavior, is a list of "recently used" files and directories. This has been deemed sufficient, because surely nobody is ever going to want to do anything new.
In the sections that follow I'll illustrate this situation with screenshots.
First, here is an example of the right way to do things. This is a screengrab of the "okular" PDF reader, which does not use GTK (it uses the "qt" toolkit instead). In this example, I first navigated down to a particular directory (for this example I made up the directory structure: $HOME/path/to/a/diretory/ ). Then I started okular from the command line with no parameters. Then I invoked the "File -> Open" dialog. (I ran this example under FVWM on a brand shiny new Arch Linux system in 2014-03.)
It also presents me with a list of likely locations on the left, which is nice but generally not useful.
This is as it should be. If you wanted to get really fancy, you could add additional lists of likely (and/or recently visited) places. But in no case should you ever take away this basic information about the CWD and deny your user the ability to work within a hierarchical file system.
Here is the same situation using, instead, the GIMP (which does use the GTK toolkit). I started the GIMP with no parameters from the command line in the same directory. (I ran this example on a 2011 vintage Kubuntu 11.10 installation running a version of GTK3 after the bug but before the fix. I set up an identical $HOME/path/to/a/directory structure so as to make the two examples comparable.)
We can only open the file we want ($HOME/path/to/a/directory/test1.jpg) by clicking on "dmm" (my home directory) on the left, and then clicking on the directory names in sequence. Click on "path", click on "to", click on "a", click on "directory". Only then will the GTK FileChooser show us the files which were right there in the directory where we started the GIMP. We've had to teleport out of our workshop and walk back into the house just to be able to pick up a screwdriver.
I try to be a person of gentle language, but it is difficult to react to this without the language of sailors. So I'll simply observe that this is insane. In saying this, I'm not trying to be rude or snarky. "Insane" here is not intended as an insult. It is intended as a clinical description. This user interface is divorced both from the reality of computer science and the reality of our physical world. It has as little relationship to reality as someone in a padded cell who thinks she's Napoleon.
Aside: You can start the GIMP with a filename parameter while in a directory, and GTK will understand the CWD for opening and for saving/exporting that same file. But if in this very same GIMP session you create a new image ("File -> New") GTK will throw away the CWD for it and present you with a "nowhere" dialog of recently used files. It's as if you built something new in your workshop and tried to set it down on the table in the corner, but because you haven't been over to that corner recently you have to teleport outdoors, walk inside, walk to your workshop, and walk over to the corner. It's like living inside a Kafka novel. Moreover, you don't always have an image file you want to open beforehand. So you can keep a sample blank image file in a handy location (e.g., $HOME) and cp it into the CWD and then open the GIMP on it. There's elegance for you.
Fortunately, as described earlier, the developer responsible for this aspect of GTK has added an option to revert back to sane behavior. It's hidden, but it is there. Here's a screengrab of the GIMP opened in the same directory with:
LocationMode=filename-entry StartupMode=cwd
in my ~/.config/gtk-2.0/gtkfilechooser.ini configuration file. The "LocationMode=filename-entry" gives you the text entry box and the "StartupMode=cwd" restores the concept of the CWD. (I ran the example below under FVWM on a new Arch Linux system in 2014-03.)
The dialog as shown above doesn't show the "Location" text entry box. You have to click on the little pencil icon in the upper left to get that:
This is fixed; we can use it. Still, it is regrettable this is not default behavior. You have to go out of your way to fix a basic part of your system in order to make GTK applications such as the GIMP usable again.
With this CWD design bug fixed in GTK and GTK-based applications, you can imagine my dismay when on a freshly installed system in 2014 I discovered that an analogous bug was also present in some (but not all) KDE applications. I found this in some applications that I'd been using all along (but had thought must be GTK applications because they displayed this bug) - the CAD programs "LibreCAD" and "FreeCAD" are examples. I found it in some new-to-me applications which are more tightly integrated into the overall KDE experience - the "Krita" image program, for example. But, curiously, I did not find it in the KDE PDF viewer, "Okular" (which works perfectly).
[STATUS: There is a deeper puzzle here, because the problem with Krita was fixed and checked in to its source tree. Yet the problem remains. It seems as if for some reason many KDE applications are calling a completely different version of a file choosing dialog which not only does not present the CWD but doesn't even present a "recent" option. This is of course very annoying. I'm still looking in to it.
All portions of this document not noted otherwise are Copyright © 2014 by David M. MacMillan and Rollande Krandall.
Circuitous Root is a Registered Trademark of David M. MacMillan and Rollande Krandall.
This work is licensed under the Creative Commons "Attribution - ShareAlike" license. See http://creativecommons.org/licenses/by-sa/3.0/ for its terms.
Presented originally by Circuitous Root®
Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]
