[IPython-dev] notebook composition UI thoughts

[Hans Meine]

(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 
possibility:

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.

Greetings,
  Hans