[IPython-dev] notebook composition UI thoughts
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
That's what I wanted to say.
More information about the IPython-dev