Tim Starling wrote: > 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.
Going for the first option would be best. It's not that easy to implement, but once done it should avoid problems in the future. Note that with ":gui" you can start the GUI any time, also with a modified buffer. That's why option 2 is not acceptable. -- If the Universe is constantly expanding, why can't I ever find a parking space? /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- 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
