First of all, belated thanks to Bram for applying my patch in July 2010 to fix GtkFileChooser (2301:6f63294a1781).
I upgraded recently from Ubuntu 10.10 to 11.04. After the upgrade, I noticed that GtkFileChooser was broken in gvim. The problem is rather strange: when you navigate from one directory to another, about 30-50% of the time it fails to actually go to the directory. The button is highlighted, but the main file listing stays the same. The problem occurs when double-clicking the directory in the main file listing, clicking a shortcut, or clicking one of the parent buttons at the top of the box. When it happens on double-click, the mouse cursor changes to "busy" until you do something to make it change back. I naturally assumed that it's my fault, so I investigated. It looks like it's not my fault. I discovered that it only happens when vim forks. The problem goes away if you use gvim -f. So I asked on IRC what the standard procedure is for early forking of a GTK+ app. The well-known GTK+ developer Emmanuele Bassi told me to fork before gtk_init() since there are some known issues with forking after gtk_init(). This is probably not one of the known issues, but rearranging gui_start() so that termcapinit() is called after fork() does indeed fix the problem. Making this into a proper patch is problematic, since the current behaviour is to attempt to start the GUI, and to only fork if the GUI can be successfully started. The options thus appear to be: 1. Fork, call gtk_init() in the child, and have the parent wait to see if the child successfully starts the GUI before exiting. If the child fails to start the GUI, the child would exit and the parent would continue. 2. Fork, call gtk_init() in the child, but don't bother with status monitoring in the parent and just exit unconditionally. The child would still be able to write an error message to stderr so the user would know what was going on. This is simpler than option 1 so it's somewhat more likely that it would get finished. 3. Work out why GtkFileChooser is breaking when you fork after gtk_init(), and fix the problem upstream in GTK+. This is the most complicated, and would leave vim vulnerable to future breakage because we would be continuing to use GTK+ in an unexpected and unsupported way. Advice would be appreciated. -- Tim Starling -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
