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
