[IPython-dev] Bumping up priority of thinking about output scrolling/control
benjaminrk at gmail.com
Fri Jun 1 00:51:46 EDT 2012
On Thu, May 31, 2012 at 8:30 PM, Fernando Perez <fperez.net at gmail.com>wrote:
> On Thu, May 31, 2012 at 8:22 PM, Brian Granger <ellisonbg at gmail.com>
> > i can look into this. But the other option for the output of multiple
> > engines is to build a simple widget that has a slider and allows you
> > the slide through the output of the different engines. But I agree
> > that we need a more general solution to this issue.
> I think it's worth thining about the clean solution for the long run:
> Titus had examples that were unmanageable even without any
> parallelism, simply because of very long running code that had super
> verbose stdout. Without something to manage output size, his demos
> would have been simply impossible. He actually did the public demos
> off Min's quick branch, but that's not a long-term solution :)
> So let's see what we can do for a clean solution we're happy with that
> applies even in the absence of multiple engines. Obviously your idea
> could also be quite useful for that case, but let's first think about
> what to do with stdout of absurd lengths...
I peeked at my old branch, and did a cleaner version here:
It's simple CSS as suggested
but required a slightly ugly workaround for the fact that FF's box-model
doesn't properly measure the height of max-height limited children
(container height is calculated ignoring max-height truncation). The hack
is to shrink-wrap the parent, which works on FF but breaks the display on
I wouldn't say it's particularly pretty (especially on FF, but little is),
but it solves a problem.
> IPython-dev mailing list
> IPython-dev at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev