[IPython-dev] New ipythonqt console questions/feedback

[Brian Granger]

On Thu, Oct 7, 2010 at 6:15 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Oct 7, 2010 at 6:08 PM, Erik Tollerud <erik.tollerud at gmail.com> wrote:
>> This makes sense, although the more typical use case for me is wanting
>> to start up ipythonqt normally, executing something that will take a
>> while, and realizing this only *after* it's running.  So an additional
>> key-binding along the lines of the "detatch" function in screen is
>> what I was thinking of.  e.g. something that will close the qt
>> frontend without closing the kernel.  Of course, I can do this using
>> the --kernel-only flag now and then connect to that kernel, but this
>> requires planning ahead, something I do my best to avoid :)
>
> Actually your wish is not hard to implement: it would just take a
> little bit of Qt code to add a checkbox to the exit confirmation
> dialog, saying 'shut kernel down on exit'.  To simply detach from the
> running kernel you would just uncheck this box and that would be it.
> The code would then avoid calling the kernel shutdown on exit.
>
> I know Evan did some work to ensure that under normal circumstances a
> kernel doesn't survive the lifespan of the client (to prevent zombie
> kernel processes when started from a GUI), but it's possible to make
> this logic optional.

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.

Cheers,

Brian

> In summary: very reasonable wishlist item, just not implemented yet.
>
>>
>> At any rate, as you say, this will hopefully become much more natural
>> to implement when the parallel framework is in place - I just wanted
>> to point out this particular use-case that I would find very useful.
>>
>>>> As soon as you have a standalone GUI that feels a terminal, exposing a
>>>> keybinding API becomes important.  We should probably ape someone else's model
>>>> for this, so as to minimize relearning for users. Do you have any examples of
>>>> nicely customizable apps for us to look at?
>>>
>>> http://code.enthought.com/projects/traits/docs/html/TUIUG/factories_advanced_extra.html#keybindingeditor
>>>
>>> <wink>  ;-)
>>
>> This is indeed the sort of thing I had in mind, but it seems natural
>> to me to expose it as an option for an ipython profile file or
>> something similar in the .ipython directory given that's currently
>> where all the configuration goes. Presumably the Traits Qt backend can
>> be examined to figure out how to do this?
>
> Yes, I hope even before something that fancy, at least we'll have
> basic text-file-based configuration available.  Keybindings should be
> part of that (though they may require a bit more work than other
> simpler options, we'll see).  Git branches from enterprising Qt users
> welcome :)
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com