On Sep 8, 11:06 am, Tim Starling <tstarl...@wikimedia.org> 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. > > -- Tim Starling
This sounds rather like what I am experiencing, tbough not identical. I am using vim-7.3 in xmonad. If I start gvim from a terminal it locks up, and I get these messages: ------------------------------------------------------------------------------------ E852: The child process failed to start the GUI [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. gvim: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. ---------------------------------------------------------------------------- It doesn't happen with other window managers. I'm using gvim -f as a workround. Apologies if I'm off-track here; I found this thread when googling for the above error. Vim: Caught deadly signal ABRT Press ENTER or type command to continueVim: Finished. -- 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
