<div>I don&#39;t think it&#39;s as hard as you make it sound.</div><div><br></div><div>I just changed the close dialog so it has 3 options: </div><div>a) full shutdown, </div><div>b) only close console, </div>
<div>c) Cancel; forget we ever met.</div><div><br></div><div>I only added case b), and it&#39;s just a few lines.</div><div><br></div><div>see here:</div><div><a href="http://github.com/minrk/ipython/commit/cdb78a95f99540790cdf7960e52941d2ef1af2a3" target="_blank">http://github.com/minrk/ipython/commit/cdb78a95f99540790cdf7960e52941d2ef1af2a3</a></div>


<div><br></div><div>The only thing that *doesn&#39;t* seem to work, is that you have to ctrl-C or some such to terminate the original Qt process if you close the original console.  Other consoles can shutdown the kernel later, but the process doesn&#39;t die.</div>

<div><br></div><div>Note: this is really a proof of concept.  Yes/No/Cancel is generally not a good dialog if you want things to be clear.</div>
<div><br></div><div>-MinRK<br><br><div class="gmail_quote">On Thu, Oct 7, 2010 at 18:26, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net" target="_blank">fperez.net</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Oct 7, 2010 at 6:20 PM, Brian Granger &lt;<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>&gt; wrote:<br>



&gt;<br>
&gt; The only difficulty is that the kernel has to know when it is started<br>
&gt; if is can outlive its frontend.  This is the logic that makes sure we<br>
&gt; don&#39;t get zombie kernel floating around - we don&#39;t want to turn that<br>
&gt; logic off under normal curcumstances.  We will have to think carefully<br>
&gt; about this.<br>
&gt;<br>
<br>
</div>We could allow the user to disable the auto-destruct behavior on<br>
startup.  Basically advanced users who know they&#39;ll have to clean up<br>
their kernels manually could disable this logic on startup. Then at<br>
least they&#39;d have the choice of disconnecting the frontend later on if<br>
they so desire.<br>
<br>
That wouldn&#39;t be much of an issue for kernels started manually at a<br>
terminal, since you can always kill the kernel right there.  The<br>
automatic logic is really important once clients are started from a<br>
gui/menu, where there&#39;s no easy/obvious way to find a zombie kernel<br>
short of low-level process identification.<br>
<br>
But I think that making that logic optional with a startup flag is a<br>
reasonable compromise: only advanced users will knowingly disable it,<br>
and it won&#39;t cause zombie kernels under normal use.<br>
<div><div></div><div><br>
Cheers,<br>
<br>
f<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br></div>