[IPython-dev] New ipythonqt console questions/feedback

[MinRK]

I don't think it's as hard as you make it sound.

I just changed the close dialog so it has 3 options:
a) full shutdown,
b) only close console,
c) Cancel; forget we ever met.

I only added case b), and it's just a few lines.

see here:
http://github.com/minrk/ipython/commit/cdb78a95f99540790cdf7960e52941d2ef1af2a3

The only thing that *doesn'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't die.

Note: this is really a proof of concept.  Yes/No/Cancel is generally not a
good dialog if you want things to be clear.

-MinRK

On Thu, Oct 7, 2010 at 18:26, Fernando Perez <fperez.net at gmail.com> wrote:

> On Thu, Oct 7, 2010 at 6:20 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> >
> > The only difficulty is that the kernel has to know when it is started
> > if is can outlive its frontend.  This is the logic that makes sure we
> > don't get zombie kernel floating around - we don't want to turn that
> > logic off under normal curcumstances.  We will have to think carefully
> > about this.
> >
>
> We could allow the user to disable the auto-destruct behavior on
> startup.  Basically advanced users who know they'll have to clean up
> their kernels manually could disable this logic on startup. Then at
> least they'd have the choice of disconnecting the frontend later on if
> they so desire.
>
> That wouldn't be much of an issue for kernels started manually at a
> terminal, since you can always kill the kernel right there.  The
> automatic logic is really important once clients are started from a
> gui/menu, where there's no easy/obvious way to find a zombie kernel
> short of low-level process identification.
>
> But I think that making that logic optional with a startup flag is a
> reasonable compromise: only advanced users will knowingly disable it,
> and it won't cause zombie kernels under normal use.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101007/4c321fb6/attachment.html>