Some notebook tweaks.

[Carreau]

I'm looking at wether I can make the notebook more "console-like"

( tweeked notebook vs qtconsole )

So here are 3 little changes (to start) that would make the customization a little easier.

Allow easier prompt customization with continuation prompt.
Add a convenient 'insert_cell_at_bottom' function
And slightly tweak css so that Input and Ouput are better aligned vertically.

[ellisonbg]

I am probably -1 on this. In my mind the benefit of the notebook is that we are free from the constraints of the console look and feel. In a terminal/console context, the continuation prompts serve a real purpose - to help the user line up additional lines of code. In the notebook,that purpose is served by the shading of the input area so continuation prompts only add visual clutter.

A few other points:

• We make a lot of UI design choices based on the format of the prompts. I don't see people needing to do prompt customization in the notebook enough that it warrants messing with all of that.
• Can you describe the css mods that you made. They might make sense even if the other changes don't go through.
• What does insert_cell_at_bottom do?

[Carreau]

I am probably -1 on this. In my mind the benefit of the notebook is that we are free from the constraints of the console look and feel. In a terminal/console context, the continuation prompts serve a real purpose - to help the user line up additional lines of code. In the notebook,that purpose is served by the shading of the input area so continuation prompts only add visual clutter.

My point is not on transforming the notebook into a console. Don't worry.
I just think of most of notebook component as a re-utilisable part. So the first goal of this PR is to extend possibility without changing the actual way of working.

I also think that we'll came to a point where people will brand the notebook, or may not like the cell "shading".
Personally, I like full white notebook with continuation prompt, but maybe 'continuation prompt' is a bad word.
You could say 'multi_line_input_prompt' where if the cell is more than one line, then you are allowed to add informations, so I only give an option to "make" one

To be clear, the "visible part" of this PR only shift the output area of a few pixel to top left.

The rest is a convenient ability to modifie prompt for codecell,
and append_cell_at_bottom that add a cell at the far end of the notebook.
It is just a convenience methods that avoid to check for the number of cell before doing insert_cell_below.

The upper capture if what could be done with ~10 lines of js/css if one would like a more "console like" webinterface. (who is thinking of embedded webkit...) which is easier to achieve with theses changes.

A long time goal would be to have most of the Js shared and why not have an
IPython nbconsole availlable.

Does that makes more sens ?

[ellisonbg]

OK thanks for clarifying this. As long as the default look/feel of the
notebook remains the same, I am fine with this. Can you provide a before
and after for the pixel shift? Am I right that you are not actually using
the append_cell_at_bottom method currently though?

On Sun, Sep 23, 2012 at 3:25 PM, Bussonnier Matthias <
notifications@github.com> wrote:

I am probably -1 on this. In my mind the benefit of the notebook is that
we are free from the constraints of the console look and feel. In a
terminal/console context, the continuation prompts serve a real purpose -
to help the user line up additional lines of code. In the notebook,that
purpose is served by the shading of the input area so continuation prompts
only add visual clutter.

My point is not on transforming the notebook into a console. Don't worry.
I just think of most of notebook component as a re-utilisable part. So the
first goal of this PR is to extend possibility without changing the actual
way of working.

I also think that we'll came to a point where people will brand the
notebook, or may not like the cell "shading".
Personally, I like full white notebook with continuation prompt, but maybe
'continuation prompt' is a bad word.
You could say 'multi_line_input_prompt' where if the cell is more than one
line, then you are allowed to add informations, so I only give an option to
"make" one

To be clear, the "visible part" of this PR only shift the output area of a
few pixel to top left.

The rest is a convenient ability to modifie prompt for codecell,
and append_cell_at_bottom that add a cell at the far end of the notebook.
It is just a convenience methods that avoid to check for the number of
cell before doing insert_cell_below.

The upper capture if what could be done with ~10 lines of js/css if one
would like a more "console like" webinterface. (who is thinking of embedded
webkit...) which is easier to achieve with theses changes.

A long time goal would be to have most of the Js shared and why not have
an
IPython nbconsole availlable.

Does that makes more sens ?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2421#issuecomment-8803737.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

before/after picture

input and output vertically alligned now.

Same with base text of output prompt which is now aligned with text.(used to be 1px difference, pager as guide.)

Am I right that you are not actually using the append_cell_at_bottom method currently though?

No, not yet. It is mainly for configuration/extension purposes to avoid having to re-write it.

[minrk]

input is off in exactly the same way as output, if you want them to match.

[ellisonbg]

Do you mean horizontal alignment? I don't see any vertical shift in the before and after.

Sent from my iPad

On Sep 25, 2012, at 7:36 AM, Bussonnier Matthias notifications@github.com wrote:

Same with base text of output prompt which is now aligned with text.(used to be 1px difference, pager as guide

[minrk]

Vertical alignment - there is a tiny shift in vertical alignment in the output area, but the vertical alignment was exactly the same in the input area, so if one should be fixed, so should the other.

[Carreau]

input is off in exactly the same way as output, if you want them to match.

Well I guess it is not, because you have different number of nested tags. Just look as the screen capture.

Do you mean horizontal alignment? I don't see any vertical shift in the before and after.

1px shift you really need to zoom in

Vertical alignment - there is a tiny shift in vertical alignment in the output area, but the vertical alignment was exactly the same in the input area, so if one should be fixed, so should the other.

The border of codemirror is 1px wide, I believe it does introduce a 1px shift. At least I have the 1px shift in output and not in input.

[ellisonbg]

I think we are all looking at and seeing different things. Matthias, do
you have the ability to draw on the images to show us more clearly what you
are talking about.

On Wed, Sep 26, 2012 at 4:41 AM, Bussonnier Matthias <
notifications@github.com> wrote:

input is off in exactly the same way as output, if you want them to match.

Well I guess it is not, because you have different number of nested tags.
Just look as the screen capture.

Do you mean horizontal alignment? I don't see any vertical shift in the
before and after.

1px shift you really need to zoom in

Vertical alignment - there is a tiny shift in vertical alignment in the
output area, but the vertical alignment was exactly the same in the input
area, so if one should be fixed, so should the other.

The border of codemirror is 1px wide, I believe it does introduce a 1px
shift. At least I have the 1px shift in output and not in input.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2421#issuecomment-8887000.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

ugly, but

[ellisonbg]

This part of the PR is fine.

[ellisonbg]

Good call on doing the codemirror config separately. This looks good now, merging.