[IPython-dev] notebook composition UI thoughts

Hans Meine hans_meine at gmx.net
Wed Jul 6 13:54:07 CDT 2005

(FYI: At first, I sent my answer to Michael directly by accident, I am quoting 
his answer.  I wish I were able to send mails to this list on the first 
try... ;-) )

On Wednesday 06 July 2005 19:17, Michael Tobis wrote:
> > Ideally, one could just let a dirty flag be passed down a dependency
> > graph, and highlight / gray out dirty cells, which would mean only
> > minimal effort
> Agreed; this would be nicest. I thought of this (the gray-out
> affordance is a nice touch that I missed) and considered it a bit too
> much to include in my first message.
> However, the document should vigorously complain about being saved in
> such a state.
> It's rather a complicated objective, especially if multiple undo
> operations are also supported.

My collegue got another quite cool idea; he just asked "ah, you want Python to 
do that automatically?".  Of course that'd be cool, but there's another 

By default, each cell should be it's own independent module (I think modules 
are quite cheap, right?).  In order to use stuff from another cell, "from 
cell_foo import *" could be used.  This way, dependencies would be more 
clear, and one could even use a special syntax / convention to make the 
extraction of a dependency graph an automatic procedure.

There could also be means to make several cells share a module.  I think I 
like that idea very much, because it re-uses existing technology (python 
modules).  One could also use "import foobar" and use fully-qualified 
references to results from the foobar cell.

Additionally, he still wants chapters to be totally independent of each other 
(maybe separate interpreter instances altogether).

> > OK, then the minimal, nearly trivial first fix for the problem you
> > initially presented would be to store the execution order of cells?!
> This replaces an inconsistent presentation with one that is
> consistently incorrect, which I suppose is an imporvement of a sort.
> (giving the "wrong" answer of 36 instead of 25 in the example)

It's not even really wrong; the reason for the answer is (more or less) 
clearly visible in the numbers.

> > Those are interesting problems, OTOH it's hard to save the user from
> > shooting him/herself in the foot - he/she will always need to have some
> > kind of idea of what happens behind the UI I guess.
> We can assume that anyone with an interest in authoring or modifying a
> document of this sort is not a fool, but on the other hand the user
> interface should not actively endeavor to make a fool of the author
> either.

That's what I wanted to say.


More information about the IPython-dev mailing list