<br><br><div class="gmail_quote">On Fri, Oct 8, 2010 at 15:37, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">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 class="im">On Thu, Oct 7, 2010 at 7:20 PM, MinRK &lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt; wrote:<br>
&gt; I don&#39;t think it&#39;s as hard as you make it sound.<br>
&gt; I just changed the close dialog so it has 3 options:<br>
&gt; a) full shutdown,<br>
&gt; b) only close console,<br>
&gt; c) Cancel; forget we ever met.<br>
&gt; I only added case b), and it&#39;s just a few lines.<br>
&gt; see here:<br>
&gt; <a href="http://github.com/minrk/ipython/commit/cdb78a95f99540790cdf7960e52941d2ef1af2a3" target="_blank">http://github.com/minrk/ipython/commit/cdb78a95f99540790cdf7960e52941d2ef1af2a3</a><br>
&gt; The only thing that *doesn&#39;t* seem to work, is that you have to ctrl-C or<br>
&gt; some such to terminate the original Qt process if you close the original<br>
&gt; console.  Other consoles can shutdown the kernel later, but the process<br>
&gt; doesn&#39;t die.<br>
&gt; Note: this is really a proof of concept.  Yes/No/Cancel is generally not a<br>
&gt; good dialog if you want things to be clear.<br>
<br>
</div>Thanks for the test.  The problem you note may be perhaps that you&#39;re<br>
not emitting the right signal?  I&#39;m not sure, my Qt-fu is pretty<br>
limited.<br>
<br>
But the reason I said it could be a startup flag was because I had<br>
understood that something had to be done differently *at<br>
initialization* if we wanted to bypass the logic Evan had added.<br>
<br>
Was I mistaken in that understanding?  I didn&#39;t write that code so I&#39;m<br>
not sure right now...<br></blockquote><div><br></div><div>It doesn&#39;t necessarily have to be done differently at startup, because you can &#39;destroy&#39; a widget at any point, leaving the process alive.</div><div><br>

</div><div><meta http-equiv="content-type" content="text/html; charset=utf-8">I just updated my keepkernel branch with a couple things:<div><br></div><div>1) fixed error when resetting pykernel (it still reset, but printed an error)</div>

<div>2) fixed issue where closing a frontend, even secondary ones, always shutdown the kernel</div><div>3) shutdown_reply now goes out on the pub socket, so all clients are notified</div><div>   3.a) this means that all clients can (and do) refresh the screen when a reset is called, just like the master frontend</div>

<div>4) kernel can stay alive after consoles are shutdown, and can be shutdown by any frontend at any point </div><div>   4.a) this means that a shutdown request from any frontend can close all open frontends and the kernel, even if the kernel is detached, leaving no processes zombified.</div>

<div>   4.b) 4.a required that a &#39;reset&#39; element be added to shutdown_request/reply messages to identify the difference between a real shutdown message and stage 1 of a reset.</div><div><br></div><div><a href="http://github.com/minrk/ipython/commits/keepkernel/" target="_blank">http://github.com/minrk/ipython/commits/keepkernel/</a></div>

<div><br></div><div>-MinRK</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br>
<font color="#888888"><br>
f<br>
</font></blockquote></div><br>