►
From YouTube: JupyterLab Team Meeting - November 16, 2022
Description
A meeting to share and discuss features, ideas, issues, and pull requests in JupyterLab and other Jupyter frontends. This meeting is open to anyone and everyone.
Join future calls via the Jupyter community calendar: https://docs.jupyter.org/en/latest/community/content-community.html#jupyter-community-meetings
Notes for upcoming meetings can be found on the agenda: https://hackmd.io/Y7fBMQPSQ1C08SDGI-fwtg
Past notes can be found on the JupyterLab team compass: https://github.com/jupyterlab/team-compass/issues/152
A
Okay,
hello,
everyone
and
welcome
to
the
November
16th
weekly
Jupiter
lab
call.
Today
is
a
bit
of
a
lighter
week.
We
have
16
people
on
the
call.
If
you
haven't
already
please
sign
in
to
the
agenda,
there's
links
to
it
in
the
chat
and
I.
Don't
have
any
announcements
to
make
up
top
we'll
keep
some
minutes
free
at
the
end.
In
case,
you
want
to
make
announcements
off
of
the
recorded
call
and
we'll
keep
a
section
for
additional
discussion.
A
B
Yeah
so
Anaconda
is
trying
to
like
improve
the
Jupiter
lab
extension
developer
docs,
and
we
just
have
a
mind
toward
making
that
experience
in
the
process
better
and
as
easy
as
possible
for
people
I'm
running
through
the
Jupiter
lab
extension
tutorial
right
now
and
I'm
getting
some
errors
which
I
had
brought
up
on
gitter
and
I
I
got
a
couple
of
responses,
but
if
anybody
else
has
any
suggestions
with
this
issue,
I'm
facing
I
would
appreciate
that
it
will
help
speed
me
through
this
part
of
it.
A
Have
you
opened
issue
and
either
I
guess
the
cookie
cutter,
maybe
where
you
started
or
in
lab?
If
it's
specifically
a
lab
issue,
because
Gator
is
very
transient
and
whoever
sees
it
and
answers,
you
is
kind
of
luck
of
the
draw
and
then
you
sort
of
scroll
past
people's
awareness
and
it
may
get
lost.
B
A
B
A
A
B
C
I'm
doing
I
promise
I
what
I
was
hoping
to
discuss
today.
I
know
a
few
weeks
in
the
past
I've
brought
up
some
Jupiter
lab
Reflow
proposals,
meaning
right
when
we
zoom
in
what
happens?
How
does
the
content
stay
on
the
screen?
I
can
link
link
to
the
issue
and
comment
again
in
here,
though
it
is
in
the
agenda
just
so.
It's
not
totally
weird
what
I'm
talking
about,
but
I
kind
of
wanted
to
bring
it
up
again
because
I've
heard
some
feedback,
but
not
enough
I.
C
Think
for,
like
the
the
scale
of
the
change
that
this
would
would
be
to
Jupiter
lab,
because
it's
a
pretty
big
change,
so
kind
of
opening
up
for
further
discussion.
Here,
though,
I
think
we
have
more
on
the
agenda,
so
we
may
need
to
throw
it
to
the
additional
discussion
section,
some,
but
also
I,
I'm
kind
of
thinking.
This
needs
to
be
a
vote.
C
I
know
we
try
and
avoid
doing
the
Jupiter
lab
Council
votes
if
we
can
come
to
other
consensus,
but
this
seems
like
a
really
big
change
to
me
so
I'm
also
throwing
that
out
there.
Any
of
you
can
disagree
with
that,
but
that's
kind
of
my
update
just
trying
to
keep
that
moving
forward.
So
I
will
stop
for
comments.
A
C
C
Yeah
I
can
do
that
real,
quick.
So
right
now,
based
on
the
little
bit
discussion,
we
have.
We
actually
have
three
options.
I
if
I
were
I
was
going
to
update
this
issue
regardless,
because
Mike
had
some
really
good
thoughts
on
some
other
Behavior
I
hadn't
considered
yet
so
the
first
option
is
kind
of
what
happens
now
in
the
sense
that
when
you
zoom
in
in
any
way
it
reflows
by
prioritizing
like
the
UI
around
the
document
in
Jupiter
lab
so
right,
the
panels
just
take
up
the
space.
C
The
kind
of
document
space
gets
smaller,
the
menu
gets
larger
and
we
can
continue
doing
that
and
just
we
have
to
make
certain
fixes,
because
right
now,
when
that
happens,
we're
still
losing
things
on
the
way
it
scales.
But
so
that's
like
the
first
thing,
is
kind
of
the
current
behavior,
but
a
little
more
polished.
The
second
approach
would
be
to
say,
hey.
Actually,
the
document
is
the
most
important
thing
to
us
in
Jupiter
lab.
C
So
when
we
start
zooming
in,
we
start
collapsing
some
of
the
UI
there's
more
specifics
on
that
in
the
issue.
But
like
there's
very
proposals,
we
do
currently
have
the
sidebars
collapse,
but
even
the
sidebar,
like
the
width
of
them
with
a
sidebar,
gets
really
large
and
then,
when
you
expand
it,
it
usually
takes
up
most
of
the
screen
after
a
certain
Zoom
Point.
C
So
that
would
be
the
other
to
say.
Hey
we
start
collapsing,
some
of
the
UI
start,
throwing
more
things
in
the
command
palette,
make
the
command
palette
more
available
on
the
home
screen,
instead
of
just
being
hidden
in
a
menu
and
the
third
option.
C
That's
based
on
feedback
from
Mike
is
the
document
is
the
priority,
but
the
idea
that
Zoom
Behavior
kind
of
only
acts
on
the
document
and
that
if
you
want
to
have
larger
UI,
that's
like
preferences
like
that's
a
setting
that
you
choose
rather
than
that
that
might
be
kind
of
reminiscent
of
I,
don't
know
I'm
thinking
like
I,
think
that's
kind
of
what
Microsoft
Word
does.
If
you
zoom
in
right,
the
document
gets
bigger
before
the
UI.
So
that's
my
summary
of
the
three
thanks.
C
A
All
right,
folks,
how
about
we
go
through
the
agenda
but
return
to
this.
So
please
have
this
in
the
back
of
your
minds,
but
for
now
we'll
move
on
to
William.
A
D
Just
have
a
quick
remark
that,
like
three
days
ago,
one
of
the
users
of
cocalc,
where
we
also
have
Jupiter
like
plain
vanilla,
Jupiter
lab
running
with
the
potential
of
being
collaborative,
had
like
a
list
of
reproducible
steps
which
led
to
something
that
felt
a
lot
like
we
all
experienced
last
week
when
we
were
testing
real-time
collaboration,
where
they
could
make
changes,
but
they
couldn't
actually
save
them
to
disk
so
anybody's.
Looking
into
this
problem,
they
might
find
these
steps
of
value
to
try
out,
but
it's
basically
for
them.
D
It
was
like
what
triggered
it
was
very
different.
It
was
having
the
notebook
server,
stop
and
then
get
restarted,
and
but
the
experience
they
had
on
their
side
was
very
similar
to
what
we
experienced.
So
there
might
be
some
relationship
involving
initializing
the
state
between
the
back
end
and
the
front
end.
So
I
just
wanted
to
toss
that
out.
There.
A
Thanks
for
this
recipe,
this
is
helpful
David,
who
is
on
the
call,
has
been
working
on
this
and
I
wonder
if
this
is
in
line
with
the
changes
you've
been
making.
E
There
are
really
probably
some
issues
in
the
previous
releases
Alpha
releases,
so
I'm
not
really
surprised,
but
this
it
should
be
fixed
soon.
E
It's
not
even
enough
yeah,
then
that's
a
really
kind
of
old
already
so
yeah
I,
don't
know
it's
too
old
to
say
what
was
wrong.
There
was
a
couple
of
issues
in
the
past,
so
yeah
I
can't
really
help
here.
Okay,.
E
A
William
for
your
purposes,
if
you
want
a
3.x
line
and
you
want
to
have
a
test-
that's
closer
to
the
one
we
did
last
week,
the
next
3.6
release,
whether
it's
an
alpha
or
a
beta,
will
have
basically
the
latest
attempts
to
fix
these
kinds
of
issues.
So
when
that
comes
out,
that's
the
one
I
think
you
might
Target
and
test
next.
Okay:
cool
cool.
Thank
you
for
reporting
back,
though
this
is
helpful,
all
right
cool!
Well,
does
anyone
have
anything
they
would
like
to
add
to
the
regular
agenda?
A
If
not,
we
have
one
discussion.
Item
added,
and
we
also
have
Isabella's
item
that
she
just
talked
about,
but
I'll
give
you
a
chance
in
case
there's
something
you've
been
holding
back
on.
F
Got
a
quick
question
or
a
proposal,
so
we've
been
migrating
some
some
of
the
repos
to
use
releaser
from
the
Repository,
including
a
couple
that
use
npms
a
Jupiter
scheduler
has
an
npm
package
and
Jupiter
resource
usage,
I'm
wondering
if
we
want
to
do
that
for
lumino
and
Jupiter
lab,
given
that
we
have
positive
experience
on
the
other
ones
and
I
mean
so
so.
The
security
risk
there
is
that
we're
using
shared
credentials
and
there's
and
the
credentials
would
be
on
the
repository.
F
But
the
mitigation
is
the
fact
that
whoever's
running
the
the
commit
or
the
workflow
we
validate
that
they're,
an
admin
on
that
particular
repo,
so
lumino
or
or
Jupiter
lab
so
I
I
can
propose
this
on
the
team
Compass.
If
that
makes
sense
to
do
that
or
if
it's
kind
of
a
non-issue
at
this
point,
we
can
just
go
ahead
and
do
it.
F
So
that
is
the
Jupiter
lab
bot
account
for
each
of
those,
so
it
uses
scoped
Pipi
token,
because
those
exist
for
lab
and
lumino
sorry
Lumina
doesn't
even
have
a
Jupiter
pack,
a
Pi
Pi
package
for
the
npm
side.
There's
no
such
thing
as
a
scope
token,
so
it's
just
a
pure
release
token,
and
that
jupyter
lab
bot
only
has
release
capability.
It
doesn't
have
admin
access
to
the
npm
side.
F
So
what
you'd
see
at
least
on
that
on
Pi
Pi
for
Jupiter
lab
would
on
the
security
tab.
If
you're
an
owner
is
a
release
event
from
the
Jupiter
lab
bot
account
and
then,
if
you
go
to
look
at
the
commit
history,
the
commit
is
whoever
triggered
it,
their
generic
their
it'll
be
their
handle
and
their
generic
GitHub
I
forget
the
the
what
it
is.
F
It's
a
so
if
your
email
is
private,
it's
the
one
that
will
work
and
associate
with
your
avatar
so
show
up
as
whoever
released
it
in
the
commit
history.
Just
not
with
your
private
email
address,
foreign.
F
So
it's
it's
actually
validating
that
you're,
an
admin
on
the
target
repo.
So
you
can't
I
I
mean
if
you're
using
Jupiter
releaser
from
your
fork,
then
that's
a
different
story.
Actually,
no,
it
still
is
doing
the
validation.
F
F
Yeah,
if
it
can't
read
the
user
thing,
it
means
that
the
bot
account's
not
set
up
right
and
if
it
reads
that
you're,
not
an
admin
or
out,
say
I'm
not
going
to
allow
this.
G
All
right
from
a
security
perspective
is
there
a
case
like
a
a
bad
case
where
it
doesn't
notice
that
you
don't
have
admin
rights
and
it
still
lets
you
push
to
it.
Repo
you're
not
supposed
to.
F
That
would
be
a
GitHub
API,
given
the
wrong
answer
back.
Okay,
so
because
it's
actually
it's
actually
calling
a
rest
endpoint
an
API
GitHub
to
get
your
user
status.
G
F
Yes,
it's
time
for
GitHub
for
that,
okay
and
it's
it's
it
there's
a
there's.
A
one
of
the
event
parameters
is
a
GitHub
I
forget
what
it's
called,
but
it's
the
person
who
actually
triggered
the
workflow.
So
if
you
re-triggered
someone
else's
workflow,
it
would
show
up
as
your
credentials
and
and
check
that
user
to
be
an
admin.
H
Steve,
let
me
rephrase
my
question.
You
mentioned
that
there
was
a
risk
from
shared
credentials
what
it,
what
what
are
the
ramifications
of
that
risk.
F
F
For
you
know,
I,
don't
we
don't
get
alerts
if
someone
publishes
the
Pi
Pi
per
se,
but
if
someone
else
got
the
account
credentials,
but
they
all
had
two-factor
authorization
on
them
and
they're
being
protected
by
GitHub
Secrets,
which
by
default,
will
not
print,
even
if
you
print
them
to
the
console
they
get
detected
and
obfuscated.
F
So
I
hadn't
seen
a
threat
angle,
but
I
yeah.
If
someone
notices
one
I'd
be
happy
to
know
that,
so
we
can
adjust,
but
we've
been
like
trying
to
find
all
the
holes
that
might
we
might
be
exposing
here
over
time,
so
I.
G
G
F
That's
that
yes,
but
on
the
pipi
side
an
admin
could
actually
no
you
couldn't
even
you'd
have
to
like
you'd
have
to
be
a
pretty
Rogue
admin
on
the
on
the
account
to
get
access
to
the
to
the
Bots
token,
and
even
that
is
only
it's.
It's
a
scope
token
for
that
to
release
on
that
one
package
and
for
yeah
I'm.
F
Not
if
someone
has
right
access,
they
might
be
able
to
like
somehow
leak
those
to
themselves,
but
I,
don't
know
how
they
would
do
that
I
guess,
maybe
if
they
yeah
I,
don't
want
to
talk.
G
F
Yeah
so
I
yeah,
so
I
guess.
The
question
is
whether
someone
with
right
access
and
not
admin
access
could
access
this
the
bot
credentials
and
then
make
Rogue
releases
as
as
like
the
as
I
I,
think
what
you're
getting
at
Alex.
I
F
I
G
F
Yeah,
it
has
two
Factor
off
on
all
these
accounts:
Pi
Pi,
GitHub,
npm
Etc,
the
email
accounts.
H
F
If
you
had
access,
if
you
got
access
to
the
GitHub
but
or
the
the
pipei
token
the
scope
token,
then
you
could
basically
impersonate
that
bot,
but
that's
the
same
of
any
scoped
Pi
Pi
token.
To
answer
your
question:
we
do
Grant
this
bought
access
to
push
because
it's
actually
pushing
the
commit
and
tags
for
the
release.
D
F
And
right
now
so
there's
a
new
beta
thing
for
Scopes
access
tokens,
personal
access,
tokens
that
I
open
initial
and
releaser
to
look
into
that.
Ideally,
those
would
also
be
scoped
to
the
to
that
particular
repo,
so
that
the
bot
would
only
have
access
with
that
token
to
that
repo.
But
right
now
it's
it's
whatever
that
the
bot
has
access
to
and
there's
one
block
per
GitHub
org
right
now
is
so
IPython
Jupiter
lab
Jupiter
server
and
Jupiter
Etc
setup,
Bots
stuff
right
now,.
F
F
But
yeah
anything
we
can
do
to
scope
it
down
like
on
the
npm
side.
The
fact
you
can't
have
scope
tokens
I
think
it's
it's
good
to
minimize
the
the
the
reach.
As
far
as
you
can.
A
G
Yeah
that
was
gonna,
be.
My
question
is
like:
will
the
other
release
things
still
work
like?
Would
we
still
be
able
to
absolutely
sure
1.x
or
do
a
manual
release?
Of
course,
we
could
always
do
a
manual
release,
but
what
really
still
work,
if
you
like,
did
it
on
a
fork.
F
H
F
And
that's
that's!
Actually
what
Jeremy
and
Fred
had
to
do
for
a
little
while
is,
is
make
releases
from
the
previous
branch
and
tag
of
releaser
on
1.x,
before
Jupiter
lab,
Maine
and
3.6,
or
whatever
supported,
release
or
V2
workflows.
F
Even
no
so
even
release
or
B2
allows
you
to
release
from
your
fork
still.
So
that's
that's
all.
That's
still
going
to
be
there
so
yeah.
It
basically
would
open
both
options
to
Jupiter
lab,
so
you
could
either
run
it
from
your
fork
or
run
it
from
Jupiter
lab
itself.
G
G
E
K
K
Guess
two
things
was
that
I
I
guess
I've
encountered
some
situations
and
been
working
around
situations
where
some
of
the
internal
classes
are
problematic
to
use
in
those
contexts,
and
there
are
maybe
changes
that
could
be
made
to
make
that
easier
to
consume
them
and
so
I'm.
Just
my
question
was
sort
of
in
two
ways
is:
does
stupid
a
lot?
K
Have
any
sort
of
Downstream
dependencies
at
the
moment
that
isn't
that
you
can
the
sort
of
Team
considers
that
isn't
the
whole
application,
so
something
a
little
bit
like
the
TV
use
case
and
also
a
side
of
that?
What's
the
best
way
to
start
I
guess
raising
issues
like
this
and
starting
some
discussion
on
whether
some
changes
could
be
made
or
or
whether,
like
a
downstream
thing
like
TV,
could
be
supported.
I
So
yeah
for
a
simple
case
using
the
part
of
Jupiter
lab,
it's
in
Jupiter
lab
itself,
I
think
it's
the
best
best
sources.
We
have
an
example
folder
that
has
some
some
remixed
of
the
various
pieces
of
the
code
for
doing
simpler
application,
so
because,
basically
most
of
the
code
is
in
Jupiter
lab
itself.
The
major
dependency
that
we
get
is
the
lumino
library
that
we
are
also
maintaining.
I
But
it's
more
about
the
interface
and
some
some
features
like
this
signal
thing
that
we
can
use
for
exchanging
information
between
various
pieces
of
the
of
the
software
regarding
improving
reusability.
The
best
is
to
open
issue
directly
on
the
GitHub
Jupiter
lab
Repository,
and
we
will
gladly
improve
that
part.
I'm
pretty
sure
like
there
are
things
like
that.
Are
private
and
could
be
moved
to
protect
it
and
stuff
like
that
for
easier,
re-implementations,
so
yeah,
it's
always
more
true
yeah.
I
A
So
so
yeah
you're
you're,
pointing
out
the
examples
is,
is
a
really
good
place.
The
other
thing
is
that
the
two
example
sorry
I'm
using
the
word
example,
the
two
libraries
you
specifically
mentioned
services
and
output
area-
are
quite
different,
so
Services
because
it
has
no
UI
component-
is
fairly
straightforward.
One
to
fold
into
your
application
and
even
apps,
very
different
from
Jupiter
lab,
like
vs
code
use
the
services
package,
things
that
are
UI
like
output
area.
A
There
are
multiple
paradigms
for
building
uis,
that
Jupiter
applications
use
and
support.
We
have
some
components
that
are
react
components.
We
have
some
components
that
are
the
widgets
of
the
lumino
library
that
underlies
Jupiter
lab,
and
we
have
some
components
that
are
Composites
because
they
might
bring
in
a
react
a
bit
and
they
might
wrap
that
in
a
lumino
widget
and
then
consume
it
that
way.
So,
hopefully
there
are
examples
that
are
analogous
to
what
you
want
to
do
for
using
something
like
react,
plus
remix.
A
The
life
cycle
of
Jupiter
lab
components
that
are
widgets
is
slightly
different
than
the
life
cycle
of
a
react
component,
but
it
can
be
made
to
sort
of
play
nice
basically
but
yeah
if
it
turns
out
that
either.
There's
no
example
that
gives
you
a
usable
enough
starting
point
or
if
it's
the
case,
that
just
the
API
of
output
area
or
some
other
widget
that
you're
using
is
insufficient
to
your
needs.
Yeah,
please
open
up
issues
in
the
main
jukebox
repo.
A
A
K
Right,
cool,
okay,
cool
thanks
I
will
I
will
go
ahead
and
open
some
issues.
I
think
that
I
haven't
looked
in
depth
in
the
examples
folder.
So
thanks
to
point
me
then,
and
I
guess:
there's
a
there's
a
sort
of
spectrum
of
different
like
things
or
changes
from
ranging
from
like
the
structure
of
the
Imports
I
guess
through
to
questions
like
it,
should
should
be
using
the
sort
of
Jupiter
front-end
plug-in
system
as
a
way
to
then
go
and
wait.
K
A
You
all
right
shall
we
revisit
Isabella's
Reflow
proposal
about
zooming
in
Jupiter,
lab.
C
G
I
actually
had
a
follow-up
question
on
that
Isabella,
so
the
the
different
proposals
sounded
interesting,
but
I
was
having
trouble
figuring
out
what
the
use
case
for
this
Zoom
was
yeah.
A
G
C
That's
a
good
point:
I
think
the
difficult
thing
with
it
is
well.
I
have
right
motivations
and
that
I'm
coming
to
this
for
an
accessibility
perspective,
so
I
am
kind
of
right,
I'm,
I'm,
leaning
more
towards
some
of
that
low
vision.
Support,
although
I
would
not
say
that,
like
mobile
is
not
an
accessibility
accommodation,
but
at
the
same
time
we
I
don't
know
if
we
can
decide
based
on
one
of
those
axes,
I
don't
think
we
can
in
fact
right.
People
use
this
for
a
lot
of
different
things.
C
So,
yes,
I
would
like
those
to
be
included.
That
was
kind
of
my
motivation
is
specifically.
There
is
a
category
web
content,
accessibility
guidelines,
a
standard
that
discusses
kind
of
expected,
Reflow
Behavior
I,
can
link
that
in
the
chat.
If
you
want
I,
think
it's
in
the
issue,
and
so
my
motivation
is
I'm
trying
to
get
us
to
meet
more
of
those
standards,
and
that
would
include
having
this
Reflow,
which
the
criteria
is
kind
of
like
all.
C
The
content
needs
to
be
on
the
page
without
horizontal
scroll
bars
unless
you're
under
a
certain
size
and
on
the
page,
meaning
like
you,
can
have
a
vertical
scroll.
That's
just
trying
to
not
like
have
it
kind
of
overflowing
in
the
window.
So
just
like
trying
to
be
honest,
that's
my
motivation,
but
at
the
same
time
I
think
one
of
the
times
I
brought
this
up.
It
was
like
oh
I
want
this.
You
know
more
for
presentations
right.
That
I
want
to
make
sure
I
know.
C
G
In
that
case,
it
feels
like
the
toolbars
need
to
be
zoomed
in
too,
because
there's
cases
where
you
need
to
be
able
to
see
the
toolbars,
because
they're
too
small,
so
I
I,
feel
like
we
need
to
let
the
toolbar
zoom
in
too
and
then
it's
a
question
of
how
do
we
handle
when
you
zoom
in
too
far,
because
I
think
of
certain
web
I.
Think
of
a
lot
of
websites
where,
like,
if
you
zoom
in
far
enough,
it
hides
menus
or.
G
Instance,
if
you
you'd,
hide
the
sidebars
entirely
and
if
you
wanted
to
open
them,
they'd
replace
the
whole
screen,
but
that's
a
very
I
lost
some
web
term.
I'll
said
modular,
yeah
I
lost
the
web
term
a
way
of
going
about
it
like
it's
a
very
mobile-centric
way
of
going
about
it
and
we
have,
as
far
as
I
know
done
almost
none
of
that
type
of
development.
Inside
of
Jupiter
lab
right
now,.
C
I
think
there
was
some
effort,
I
don't
know
too
much
about
it.
I
might
be
calling
people
I
feel
like
I
feel,
like
Jeremy
actually
did
some
work
on
mobile
stuff
at
one
point,
but
correct
me:
if
I'm
wrong
so
I
know
there
has
been
something
I'm,
not
totally
sure
what
the
current
state
is.
There.
G
We
go
Gabriel
put
in
the
chat,
responsive
development.
A
Yeah
so
there's
very
slow,
moving
progress
towards
some
sort
of
tablet
and
mobile
support.
Recently
we
switched
most,
but
not
all,
with
the
notable
exception
of
data
grid.
Most
lumino
packages
now
listen
to
pointer
events
instead
of
mouse
specific
events.
A
The
initial
motivation
for
the
what
I
can't
remember
whether
we
call
the
mode
or
format
attribute
of
the
Jupiter
front
end
was
to
have
things
like
desktop
mobile
tablet,
but
that's
not
how
it
panned
out,
but
we
did
put
in
for
a
while
some
media
queries
to
that
end
as
well.
But
really
we
haven't
had
a
coherent
and
targeted
effort
to
support
non-desttop
browsers,
yet
I
think
notebook.
A
7
is
a
good
place
to
start
an
effort
like
that,
because
it's
built
with
Jupiter
lab
components
and
because
it's
got
such
a
smaller
surface
area
from
an
end
user
perspective,
there's
fewer
user
Journeys
to
cover.
So
it
seems
like
an
easier
Target
to
make
mobile
friendly,
but
yeah.
There
isn't
really
more
than
that.
G
E
L
Yeah
I,
just
wanted
to
add
on
this,
like
most
of
the
recent
defaults
were
just
to
you
know,
try
to
remove
some
things
that
were
not
necessarily
use
food
on
mobile,
so
notebook
7
is
really
it's
really
just
a
notebook
on
the
page.
So
on
mobile
is
working
pretty
nicely
with
lab.
Is
you
still
have
like
this
side
side
panels
that
kind
of
are
in
the
way,
but
it
for
now
is
only
mostly
being
just.
L
A
M
A
Think,
at
least,
if
there
were
only
one
way
we
were
doing
it.
If
there
weren't
like
multiple
ways
of
of
handling
Zoom
for
different
kinds
of
users,
then
the
one
sort
of
lowest
common
denominator
use
case
is
we
make
the
toolbar
expand
and
the
document
expands
so
that
the
things
that
you
want
to
do
when
you
have
this
thing
open
are
the
things
that
are
available
to
you
in
this
zoomed
in.
B
A
C
And
I'd
like
to
note
they're,
not
mutually
exclusive,
like
right
now,
I
believe
that
there
is
a
setting
that
allows
you
to
change.
It's
basically
allowing
you
to
change
the
value
of
the
UI
font.
Variable
right,
like
that
CSS
variable,
I,
have
to
say
I'm,
not
sure
if
it's
working
I
haven't
posted
an
issue
because
I
haven't
been
able
to
test
it
to
see.
If
it's
like
something
on
my
end,
that's
making
it
act
wrong,
but
I
actually
can't
get
it
to
respond
right
now.
C
A
A
C
Not
quite
there
either,
but
yeah
like
I
I
could
see
both
because
that's
part
of
what
I'm
thinking
too,
since
you're
asking
Alex
like
since
we
do
need
to
be
or
I
want
to
be
centering
I
should
say
low
vision,
use
cases
regardless
of
what
screen
is
it
is
yes,
you
do
want.
You
may
need
the
UI
to
also
be
larger,
but
also
it
can
take
up
a
lot
of
real
estate,
and
then
you
can't
get
to
the
document
very
easily.
So
it's
kind
of
like.
C
G
So
yeah
follow
up
because
I
just
was
staring
at
the
other
case,
because
I
was
thinking.
Responsive
design
definitely
feels
like
something
we
should
support
and
it
would
naturally
address
the
zoom,
but
the
idea
of
just
zooming
in
in
the
main
area.
C
G
D
I
just
want
a
huge
plus
one
Alex's
suggestion
from
like
ever
in
Coco.
Can
every
single
editor
I
have
in
terminals
I
make
it
super
super
easy
to
for
every
single
panel
to
individually
Zoom
it
in
or
out
and
when
my
eyes
start
getting
tired.
Looking
at
something,
I
find
it
incredibly
useful
to
just
be
able
to
zoom
in
one
particular
piece
of
text,
and
then
sometimes
you
even
just
want
to
really
really
easily
zoom
in
and
out
things
just
to
highlight
them
or
focus
on
them
when
you're
working,
so
just
very,
very
nice.
G
C
G
C
G
C
One
thing
I
will
say,
though,
at
least
for
me
in
Firefox
is
that
I
agree.
We
should
have
something
separate
of
what
the
browser
allows
to,
but
my
like
browser
Zoom
does
allow
me
to
zoom
in
on
just
the
document
at
the
moment.
If
I
choose
to
but
yeah,
we
should
probably
have
that.
Okay,
sorry
I'm
trying
to
think
like
in
sense
of
I'm,
trying
to
keep
this
moving
forward.
So.
G
So
that
would
be
like
in
my
head.
That
would
be
like
two
features:
one
is
Jupiter
Labs
Zoom,
where
Jupiter
Labs
menu
lets
you
zoom
in
on
the
main
area
and
then
two
would
be
adding
responsive
design.
So
if
they
zoom
in,
for
instance,
using
the
web
browser
Zoom,
that
would
make
the
whole
page
bigger
like
including
the
bars
and
then
potentially
hide
them
when
you
zoom
in
too
far
like
in
a
mobile
desk
methodology,
so
they'd
be
two
different
menus.
C
C
I
guess
what
I'm
I'm
thinking
with
this
is
I
feel
like
we,
and
there
may
need
to
be
more
discussion
about
Behavior,
but
I'm,
not
sure
like
how
we
agree
in
this
case,
because
right
so
I
I
think
what
you're
saying
makes
sense.
I,
don't
know
if
anyone
else
thinks
these
things
and
I
know
it
would
impact
a
lot
of
Jupiter
lab.
Like
say,
I
magically
had
this
change
for
you
tomorrow
right
and
it
was
in
a
PR
like
how
do
we?
How
do
we
know
that
that
is
the
right
approach?
C
I
A
C
I
would
agree
I'm,
just
thinking
in
terms
of
like
right,
I
won't
be
the
one
doing
this
development,
but
I'm,
trying
to
think
in
terms
of
like
before
time
is
spent
there.
How
do
we
know
that
we're
doing
something
that
is
agreed
on
with
the
community
in
this
case,
since
we
do
have
a
few
options
that
behave
differently
right,
like
I
could
see
someone
reviewing
a
PR
for
what
we
said
and
saying
that
doesn't
make
any
sense?
Why
doesn't
it
just
clean
up
the
existing
behavior
of
Jupiter
lab
yeah.
D
C
M
I
think
we're
talking
about
interesting,
Solutions,
I'm,
not
sure.
If
we're
talking
about
accessible
Solutions,
especially
with
what
Gabriel's
said
about
the
specific
wikang
condition
right
now,
we
need
to
be
able
to
access
all
the
content.
That's
the
major
thing
that's
missing,
and
but
Reflow
is
what
the
goal
would
be.
G
C
E
G
Getting
a
paint
on
what
response
would
look
like
good
I
can
share
in
my
head.
What
I
would
imagine
a
responsive
design
would
be,
which
is
it
zooms
in
the
whole
thing,
and
after
a
certain
point,
the
sidebars
get
hidden
and
there's
a
some
sort
of
like
sandwich
logo
or
something
on
the
side
that
allows
you
to
reopen
one
or
the
other,
and
when
it's
open,
you
can
only
see
it.
You
can't
see
the
main
area
and
similarly
tabs
at
the
top.
You
might
be
able
to
scroll
away
the
tab
at
the
top.
G
The
the
status
bar
at
the
bottom
may
or
may
not
stay
there,
but
sidebars
I,
I
I.
Think
of
it
just
like.
If
you
open
up
a
mobile
web
page
and
there's
normally
a
sidebar,
that's
there
all
the
time,
but
it
eventually
gets
hidden.
If
you
open
on
mobile
with,
like
a
sandwich,
button
I
wouldn't
necessarily
be
able
to
speak
to
an
actual
ux
for
how
we'd
want
to
hide
it
and
and
show
it
again
and
how
that
would
come
out.
C
Yeah,
that's
definitely
one
pattern
I've
been
seeing
and
that
we
could
work
with
just
I
want
to
check,
though,
does
anyone
else
have
kind
of
expectations
for
this.
M
Some
of
the
presentation
tools
feel
like
more
interesting
user
experiences
to
think
about,
like
I
like
when
I'm
using
Jupiter
light
now,
I
use
Jupiter
deck
and
I
work
in
that
mode
on
mobile.
But
someone
kind
of
the
Paradigm
experiences
hint
at
something
I'd
like
in
that
space.
M
D
I
I,
just
double
checked
with
word
and
I,
see
word
is
just
literally
zooming
the
whole
document
with
no
Reflow
but
I
think
Alex.
Correct
me
if
I'm
wrong,
but
when
I
was
thumbs,
upping
your
suggestion.
I
meant
that
it
would
Reflow
the
text
like
when
you
zoom
in
it
really
just
increases
the
font,
size
and
text
flows
around
like
the
markdown
and
get
reflued.
C
Some
some
mess
with
that
too,
that
I
don't
have
an
immediate
solution
because
I'm
trying
to
figure
out
what
direction
but
I
will
also
say
because
I've
seen
this
with
testing
some
other
things,
refloating
code
is
kind
of
funky.
There's
there's
some
options
we
can
work
with,
but
so
that's
probably,
but
there
are
options
for
that.
I.
C
G
D
A
So
I
know
this
is
a
Jupiter
lab
question,
but
I
think
I
think
maybe
a
model
to
look
at
is
what
Google
Docs
does
and
to
apply
that
to
Jupiter
notebook.
Then
some
of
those
things
are
going
to
end
up
in
the
notebook
package
itself
and
we'll
see
what
that
translates
to
in
lab.
But
it's
a
much
harder
problem
to
solve
this
problem
in
lab
than
it
is
a
notebook
and
the
pieces
of
it
that
land
and
notebook
are
going
to
percolate
up
to
lab
anyway.
A
C
I
will
say:
Google
Docs
actually
does
a
pretty
bad
job
in
this.
In
my
informal
opinion,.
J
C
C
A
C
Mean
it
does
something
that
works
technically
I,
don't
want
to
say
that
they're
not
doing
something
that
doesn't
meet
those
requirements,
it's
just
a
little
messy
but
I,
also
with
the
well.
That
may
be
a
larger
thing
for
this
timeline,
I
guess
in
trying
to
figure
out
what
are
helpful
next
steps
do
I
need
to
keep
bringing
this
up
as
a
discussion.
C
My
concern,
also
with
just
having
it
here,
is
I
know
that
there
are
people
outside
of
the
Jupiter
lab
call
that
may
want
to
weigh
in
on
this
and
the
though
the
issue
exists,
I,
don't
think
it's
getting
around
to
those
people,
potentially
so
I
I,
don't
know
that's
part
of
why
I
was
looking
at
the
voting
stuff
as
well,
but
I
don't
know
if
there's
another
path
forward
or
something
that
you
all
would
prefer
me
to
do.
A
I
think
if
you
have
an
intuition
on
what
proposal
is
at
and
you
change
the
issue
to
be
a
proposal
for
that
and
Target
a
milestone
come
to
the
next
Lab
call
and
say:
okay,
this
issue
is
an
issue
we'd
like
to
release
this
way,
I'm
looking
for
volunteers
to
work
on
it,
it's
for
this
Milestone
and
here's
the
thing
we're
proposing
all
of
a
sudden
people
who
hadn't
been
talking
might
say
stuff
or
they
might
just
be
like
cool.
Let's
do
it.
K
C
Mean
there
are
a
lot
of
fixes,
no
matter
what
direction
we
do.
There
are
a
lot
of
fixes
that
need
to
be
done.
I
can
tell
you
that
that's
part
of
why
I'm
trying
to
get
the
direction,
though,
because
the
fixes
will
need
to
be
done
differently
depending
on
how
all
these
big
pieces
interact
with
one
another
yeah.