Tim Starling wrote: > On 09/09/11 05:08, Bram Moolenaar wrote: > > Tim Starling wrote: > >> 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. > > 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. > > Please find attached a Mercurial changeset which fixes the > GtkFileChooser problem with a solution along these lines. > > It turns out that for vim -g, gtk_init() is called long before > gui_start() or termcapinit(). As the RedHat bug suggested, the more > serious problem was the fact that Vim was creating a window before > forking, not that it was calling gtk_init() before forking. > > In fact termcapinit() calls gui_mch_init(), which on GTK/X11 returns > OK unconditionally. There are a few platforms where it is possible for > gui_mch_init() to return FAIL, so I tested that error case by > temporarily patching gui_mch_init() to fail unconditionally. > > It would be better if opening the X display could be delayed until > after the fork, but it looks like that would take longer to implement > than the amount of time I have to offer at the moment. The current > code works well enough for the common cases, and for the apparently > unreachable error cases, it fails without segfaulting or destroying > data. Specifically: > > * "DISPLAY=foo vim -g": gives error "E233" as it always has > * "DISPLAY=foo vim" then type ":gui" : gives the new error "E852: The > child process failed to start the GUI". The terminal is cleared and > the error message not immediately visible, but it is in :messages. > * "vim -g" with gui_mch_init patched to return FAIL: gives "E852" and > a press-enter prompt. > * "vim" then ":gui" with gui_mch_init patched to return FAIL: Terminal > modes are corrupted due to an unexpected longjmp(). However, vim is > still responsive, and "E852" is visible in :messages. > > The attached changeset starts the GUI after the fork is done. The > pre-existing pipe() code was extended to allow the child to signal to > the parent whether or not the GUI was started successfully. The first > two commits are refactoring only, the third commit is the main part of > it, and the fourth is cleanup.
Thanks, it sounds good. I'll have a look at the patch later this week. -- Engineers understand that their appearance only bothers other people and therefore it is not worth optimizing. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- 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