Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting for enabling output scrolling by default #4028

Closed
jasongrout opened this issue Feb 26, 2018 · 44 comments
Closed

Setting for enabling output scrolling by default #4028

jasongrout opened this issue Feb 26, 2018 · 44 comments

Comments

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Feb 26, 2018

From #1309 (comment), @ralexx comments:

After trying the context menu (#3545) in beta 0.31.8, I still agree with @zertrin's comment that a truncated cell view should be available by default.

I typically have many output cells in a Notebook that produce long output, and compared with classic Notebook's behavior I find it tedious to right-click through every cell that I want to see in truncated view. Classic Notebook's default truncation, as well as the ability to change state (truncated/full/collapsed) for output cells using single left clicks, worked very nicely for me.

The context menu may appeal to a wider, GUI-oriented audience. It's a neat solution. But would it be possible to allow users to retain classic Notebook's truncated output behavior as, say, a config option? As @zertrin said, otherwise it's more productive for me to stick with classic Notebook.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Feb 26, 2018

First, note that you can highlight all of the cells (Cmd A or Ctrl A) and change them to "scrolled" in one command, so you don't need to click on each one individually.

Second, our hesitation making the scrolled output a default is that the scrolled outputs created a stilted experience when scrolling through the notebook - you'd be scrolling along and then suddenly an output would capture all of your scrolling events.

That said, I'm not opposed to an option allowing one to retain the classic notebook behavior.

@bubthegreat
Copy link

@bubthegreat bubthegreat commented Feb 26, 2018

This would be easily added to configurable items - for a "autoscroll after x lines" type deal. I know that a lot of the items I use jupyter for include debug logging output when I'm doing dev work - but it seems like my specific use case is a bit more of an edge case for it's intended use. I'm using it more as an IDE for recording my investigations/bugs for others to follow along while I'm working on our internal libraries.

My use case aside, it seems like configurable values are something that would be super easy to add for things like this. If it's not set up for that already, it might be a good idea to set up some sort of "configurable_value" class that can be used for things like this with defaults and limits, so for all of these customization requests, you can just use that class for the value and add the defaults to the settings, after you've determined whether or not it's something that should be configurable by the user without significant work or significant potential impact through poor usage.

I haven't had a chance to look through the developer documentation yet.

@stsievert
Copy link
Member

@stsievert stsievert commented Feb 27, 2018

That said, I'm not opposed to an option allowing one to retain the classic notebook behavior.

I'd like to see the classic notebook behavior. Of course, this is a viewer specific option and likely a user-configurable setting. Then, I think it's a question of choosing defaults.

you'd be scrolling along and then suddenly an output would capture all of your scrolling events.

I haven't found scrolling to be an issue in the classic notebook. If I give one quick swipe on the trackpad, the momentum is strong enough it keeps scrolling (at least in latest Firefox and Safari browsers on macOS). It only matters when I trigger a scroll event on the area.

When I'm scrolling slowly, I move the mouse off to the side to continue scrolling. I've made (badly formatted) gifs of my two use cases in the classic notebook:

Slow scrolling, multiple touches Fast scrolling, one quick swipe
scroll-move scroll-single

(sorry they're badly formatted)

I prefer the behavior of the classic notebook; it gives the user more control. Based on their mouse position, they can scroll as quickly as they'd like. They can click on the side to have it partly collapse or show the entire thing.

@ralexx
Copy link

@ralexx ralexx commented Feb 27, 2018

When I'm scrolling slowly, I move the mouse off to the side to continue scrolling.

I do this as well. I suspect many Notebook users have developed this habit because of the scrolling gotcha that @jasongrout describes. For me that has been an acceptable tradeoff.

BTW good point about Select All, @jasongrout. I didn't think of that. Ultimately that is still imposing a default setting on output cell scrollability, so why not do it once as a config item? Thanks for considering this suggestion.

@SquidLord
Copy link

@SquidLord SquidLord commented Feb 28, 2018

My personal feeling is that the original Notebook behavior is far more useful, especially if you are going for a keyboard-first/keep-your-fingers-on-the-keys mode of engagement. Some programmers do. The less the hands come off the keyboard, the more focused they managed to maintain.

If anything, I would prefer that using the scroll wheel over the entire left side of the block scrolled easily just as you see the screen, and only scrolling over the text body frame itself scrolled the content. The margin that doesn't cause the content to scroll is very, very narrow on a large screen.

@ChrisMcPherson
Copy link

@ChrisMcPherson ChrisMcPherson commented Mar 2, 2018

Another behavior that in my opinion is undesirable, is that a cell set as "scrolled" will "unscroll" when that cell is rerun.

@malkiebr
Copy link

@malkiebr malkiebr commented Mar 6, 2018

It would do no harm to make cell scrolling behavior something that could be configured on the settings.
I do generate long amounts of output that I don't want to truncate, but am fine having it collapsed under the scroll area.
please consider providing this as an option for the user, even if you keep the default behavior as it is right now.

@allenyllee
Copy link

@allenyllee allenyllee commented Mar 7, 2018


Sometimes I need to train 1000 epochs or even 10000 epochs, It'll generate very long output and cause the browser very laggy and hard to scroll to the bottom to see the result. In addition, as @ChrisMcPherson had mentioned above, I've tried to set "scrolled" enable, but every time I re-run the cell, it will reset to "unscrolled".

I think the better way is to allow user to set the output length limit, says, when the output length is longer then 100 line, the cell will auto switch to "scrolled".

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Mar 7, 2018

Thanks for the feedback everyone...a few more comments:

  • We are considering making the left prompt area smaller. That makes it more difficult to put your cursor there to scroll the notebook (when outputs also scroll).
  • There are (at least) two aspects of sluggish behavior:
  1. The rendering of the output, which might be helped by scrolling output
  2. The network traffic combined with the operations of appending output and putting it into the DOM (even if off screen). IIRC @blink1073 had worked on optimizing this recently?

In the cases where I have dealt with very large output, the second aspect was strongly present, even if output scrolled. Because of this merely scrolling output won't necessarily solve the performance issues.

@zertrin
Copy link

@zertrin zertrin commented Mar 8, 2018

Thanks for acknowledging the issue.

With regards to the previous 2 comments, I would like to suggest addressing the performance issue in a separate issue. Yes performance issues need to be handled, but this is not what this issue is addressing.

The core of this issue is only about usability and user preferences. We miss the classic notebook behaviour which we found was working very well in some common use cases, where the current behaviour is just not an option to work with. (thus we are stuck with using the classic notebook for the foreseeable future)

So from this thread, I identified two actionable propositions:

  1. let the user set "default never scroll" (current behaviour) / "default scroll when output longer than X lines" (classic notebook behaviour). An additional question is deciding whether this setting is global or local to a notebook.
  2. let the user set a cell to be scrolled, and remember the decision when the cell is re-run.

My suggestion would be to address proposition number 2 "asap", which seems to be the easiest and involve the least amount of changes.

But nevertheless, proposition 1 would be needed to be able to feel comfortable coming from the classic notebook.

@yuvipanda
Copy link
Contributor

@yuvipanda yuvipanda commented Mar 10, 2018

I've a different use case here where I need output areas to be scrollable! I'm trying to do 'literate devops' in JupyterLab (http://howardism.org/Technical/Emacs/literate-devops.html), so I'm using the bash kernel instead of a Terminal. I find this approach great, since it lets me document what I'm doing both for myself and others. I'm collecting various issues that'll make this work better.

Various scrolling behavior is definitely one! In a classic Terminal, there's no collapsing of output at all - you scroll up if you wanna see what's happening. Outputs are often very large (especially if you're doing things like looking at logs, etc). Scrolling output areas in notebooks gives me a big quality of life improvement over terminals...

Right now I have to right click each output area and select this. Would be great if I can set it on a per-notebook basis!

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Mar 10, 2018

@yuvipanda
Copy link
Contributor

@yuvipanda yuvipanda commented Mar 10, 2018

@ellisonbg I just checked and unfortunately the bash kernel looks like it isn't. Is this a limitation of the Jupyter protocol or the bash kernel?

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Mar 10, 2018

@yuvipanda
Copy link
Contributor

@yuvipanda yuvipanda commented Mar 10, 2018

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Mar 10, 2018

@HalukaMB
Copy link

@HalukaMB HalukaMB commented Mar 12, 2018

Yes, also have to agree that I would approve a version with scrolling of the output above a certain number of rows. Also, maybe it is just me but I did not find the fix with "Select All" and then making all cells "scrollable". I still have to do it for each one of them or am I overlooking something?

@simonstey
Copy link

@simonstey simonstey commented Sep 19, 2018

@HalukaMB

Also, maybe it is just me but I did not find the fix with "Select All" and then making all cells "scrollable". I still have to do it for each one of them or am I overlooking something?

a bit late, but fwiw -> afaik, there is currently no "Enable Scrolling for All Outputs" option.
Instead, you have to (as noted by jasongrout in an earlier comment):

  1. press cmd/ctrl+A for selecting all cells
  2. click on "Enable Scrolling for Outputs"

that being said I was about to switch to Jupyter Lab for its ability to collapse cells, but given the fact that I would then have to enable scrolling for outputs each time I run my notebook (or any of its cells) I'm not sure that's worth the trade-off ;(

@jasongrout jasongrout removed this from the Future milestone Sep 19, 2018
@jasongrout jasongrout added this to the 1.0 milestone Sep 19, 2018
@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Sep 19, 2018

Moving to consideration for the 1.0 milestone, given that lots of people have pointed this out as a pain point.

@jvaldiviezo9
Copy link

@jvaldiviezo9 jvaldiviezo9 commented Dec 13, 2018

Any progress?

Yes, also have to agree that I would approve a version with scrolling of the output above a certain number of rows. Also, maybe it is just me but I did not find the fix with "Select All" and then making all cells "scrollable". I still have to do it for each one of them or am I overlooking something?

This is easy to implement using CSS.

.jp-OutputArea-child {
    max-height: 10em;
}

.jp-OutputArea-child .jp-OutputArea-output {
    overflow: auto;
}

Where do I need to copy that code in order to make it work?

@buckle2000
Copy link

@buckle2000 buckle2000 commented Dec 13, 2018

@jvaldiviezo9

Install a plugin like Stylus if you are using firefox. For Chrome, search "custom user style" or something like that.

Then, you can add custom CSS rules for localhost:8888/lab and paste that in.

However. this issue is what the developers of jupyterlab should solve.

@jaewooklee93
Copy link

@jaewooklee93 jaewooklee93 commented Dec 21, 2018

@buckle2000 Thank you. chrome extension stylish served well for running your CSS code

I second that this behavior should be set to default as same as jupyter notebook.

@victoryhb
Copy link

@victoryhb victoryhb commented Dec 30, 2018

I think this issue should be resolved with the highest priority. It is little UX issues like these that are driving new users away and existing users nuts.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

It's targeted to the next milestone, which is the highest priority any issue has assigned.

What is the current proposal for addressing this? Is it:

Add a new setting for notebooks, "autoscroll-outputs" which is true or false. When true, outputs by default have a max-height of ??? pixels (to be determined, perhaps from the classic notebook?). When false, the existing jlab behavior happens, which is that output is not scrolled at all.

Alternatively, the setting could be a number representing the max-height in pixels, with 0 representing to not scroll ever.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

Actually, I just checked the classic notebook. The default behavior is to not autoscroll. However, the autoscroll behavior is remembered in a cell. Is that what the proposal is here? To remember the autoscroll behavior in a cell (but not turn on autoscrolling by default)?

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

Note that in #3981 (jlab 0.33), @saulshanabrook added the capability for jlab to read the scrolled status of a cell (so if a cell is set to scrolled in the classic notebook, it will show initially as scrolled in jlab), and to save the scroll status with the special "Save notebook with view state" command. However, this scrolled state is just treated as initial state for the cell, and not state for the cell after every execution. The classic notebook behavior would be to consider that cell "scrolled" metadata after every execution, not just on notebook open.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

So perhaps the proposal here is: if a cell is set to "scrolled", keep that visual state across cell executions.

And perhaps that state should be saved by default, like in the classic notebook, instead of just being saved with the special "save with view state"?

@zertrin
Copy link

@zertrin zertrin commented Dec 30, 2018

Yes that would be the main solution to make jlab usable coming from the classic notebook.

I'm usually an early adopter, and have been willing to use jlab from the very beginning. But that single issue is the reason I still couldn't get myself to move to jlab and continue to use classic notebook to this day.

@zertrin
Copy link

@zertrin zertrin commented Dec 30, 2018

My comment on this issue from March 8th sums it up and breaks it down in 2 independent but complimentary things to implement. What you said in your last meaasge refers to the idea number 2 (set autoscroll at cell level and remember it).

Number 1 was being able to set the default behaviour at the level of the notebook (and also remember it)

Edit: it appeared that I was wrong in that comment, there is no such default to autoscroll in the classic notebook as you rightfully pointed it out.

@zertrin
Copy link

@zertrin zertrin commented Dec 30, 2018

One last thing, setting autoscroll at cell level should be very easy to do, at most 1 click (with also a keyboard shortcut if possible).

If I have 50+ cells to autoscroll individually, no way that I have to go into a menu to reach that setting. The classic notebook made it so easy (click on the area to the left of the output), something as easy should be found for jlab too.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

If I have 50+ cells to autoscroll individually, no way that I have to go into a menu to reach that setting. The classic notebook made it so easy (click on the area to the left of the output), something as easy should be found for jlab too.

Please note that you can select any number of cells and autoscroll them all at once (with either the top menu or a right click menu).

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

Thanks for responding @zertrin. So what's the consensus request for this issue? It seems that most people are asking for the classic notebook behavior, which would be respecting the autoscroll setting across cell executions. (and maybe also saving that scroll setting in the default save, instead of needing to invoke "save with view state"?)

Then in another issue, tackle the ux issues around the completely new behavior of having autoscroll on by default?

@zertrin
Copy link

@zertrin zertrin commented Dec 30, 2018

With regards to the ability to multiselect and set, duly noted. But my experience is usually that I tend to set it cell by cell as needed while growing the notebook with new cells. In that case, I cannot gain anything from the multiselection feature. So I reiterate that setting this should be as easy as possible. If there need two clicks because of right click menu, that would be already too much for heavy user. It can stay like this however, if there is a keyboard shortcut to toggle this autoscroll state at cell level.

I would agree to leave "global autoscroll on by default" out of scope temporarily, and focus on "persisting cell level autoscroll preference" immediately.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

It looks like the persistence can be done by just deleting these four lines, which turn off autoscrolling when the cell outputs are cleared:

/* Turn off scrolling outputs if there are none */
if (force) {
this.outputsScrolled = false;
}

I just tried it and it works great. I'll put in a PR shortly.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

To set a keyboard shortcut for enabling autoscroll, you can use this setting in the keyboard shortcuts in jlab 0.35:

    "notebook:enable-output-scrolling": {
      "command": "notebook:enable-output-scrolling",
      "keys": [
        "S"
      ],
      "selector": ".jp-Notebook:focus",
      "title": "Enable output scrolling",
      "category": "Notebook Cell Operations"
    }

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

Unfortunately, right now that command just enables, instead of toggling. I put in a todo item on that PR to change the command to a toggle rather than two commands, one for enabling and one for disabling.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Dec 30, 2018

If anyone on this issue wants to help with the PR #5817, please feel free to do so. I'm happy to help you get up to speed, and we would sure appreciate the help.

@futurist
Copy link
Contributor

@futurist futurist commented Jan 14, 2019

Below demo will cause the client freeze for a long time when open, does the scrolling can solve the issue?

test-freeze-test.ipynb.zip

@fadnavismehul
Copy link

@fadnavismehul fadnavismehul commented Jan 18, 2019

It looks like the persistence can be done by just deleting these four lines, which turn off autoscrolling when the cell outputs are cleared:

jupyterlab/packages/cells/src/widget.ts

Lines 761 to 764 in 3044387

/* Turn off scrolling outputs if there are none */
if (force) {
this.outputsScrolled = false;
}
I just tried it and it works great. I'll put in a PR shortly.

Hi,

Could you please explain where I can make these changes in a windows installation of jupyter lab? I am unable to find the installation directory which contains these files.

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Jan 18, 2019

I started a PR, deleting just those 4 lines: #5817

To make these changes yourself, you'll first need to set up a development install of JupyterLab. There are instructions at https://github.com/jupyterlab/jupyterlab/blob/master/CONTRIBUTING.md#setting-up-a-development-environment

@jasongrout
Copy link
Contributor Author

@jasongrout jasongrout commented Jan 26, 2019

Below demo will cause the client freeze for a long time when open, does the scrolling can solve the issue?

My guess is that it will not change freezing, since all of the text still is loaded and displayed. Is there a significant difference between the loading time in JLab vs the classic notebook?

@lock lock bot locked as resolved and limited conversation to collaborators Aug 8, 2019
@tgeorgeux tgeorgeux removed their assignment May 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.