►
From YouTube: JupyterLab Dev Meeting, July 22, 2016
Description
Meeting of the JupyterLab development team.
Meeting Notes: https://jupyter.hackpad.com/JupyterLab-Weekly-Meetings-UUJ3gIQ3iBS
B
C
Okay,
sure
so
on
to
play
I
raised
I
raised
the
multiple
complaints
that
have
come
in
about
tooltips
in
the
console
and
I
realized
the
last
major
bit
of
the
console
that
we've
been
waiting
for
a
long
time
and
I
hadn't
done
yet
his
pager
and
I
just
was
thinking
about
how
we're
gonna
deal
with
both
of
those
things.
In
addition,
last
week,
one
of
the
people
I
met
was
a
dino
for
Microsoft
and
we
talked
a
lot
about
debugging,
and
so
all
of
these
things
are
actually
really
closely
related.
C
I
think
they're
all
about
code
introspection
and
so
I
spent
this
week
working
on
that
coherent
interface.
For
that
a
way,
that's
good
to
extend
that
and
some
of
the
semantics
around
it
so
I'm
just
going
to
show
you
guys
what
my
current
outstanding
PR
about
the
console.
Pager
is
because
it
involves
more
than
just
a
pager,
and
then
I
would
suggest
that
unless
there's
a
massive
thing
that
bothers
you
about
it,
that
we
merge
them,
we
iterate
from
there
because
it's
pretty
big
and
I
think,
it'll
make
a
lot
of
complaints.
Go
away.
C
C
So
here
we
go,
this
is
a
console.
That's
been
launched
and
what's
new
is
that
sidebar,
which
has
two
tabs
in
it?
By
default,
what
we
used
to
call
hints,
I'm,
sorry,
tooltips,
I,
call
hints
and
what
we
used
to
call
pager
I'm
calling
details
because
I
think
I.
Don't
think
people
really
know
what
pager
means
once
it's
in
this
context,
but
okay,
a
great
goal.
C
So
here's
what
happens
if
I
actually
do
a
pager
now
the
issue,
the
thing
that
you
might
have
seen
happen
is
it
switched
to
the
white
one
it
switched
over
from
hints
to
details.
Basically,
when
you
add
different
inspectors,
that's
what
these
tabs
are
their
inspectors.
When
you
add
different
inspectors,
you
give
them
a
rank
and
details
always
has
a
higher
rank
than
tooltips,
because
details
is
always
something
that
was
initiated
by
a
user
action.
C
So
you
can
imagine
some
other
inspector
that
we
add
that's
also
important
and
might
have
it
a
better
rank
or
whatever,
but
for
the
time
for
the
default,
the
default
two
inspectors
are
tooltips
and
details,
though
so
we
have.
You
know
just
a
scrollable
thing
here,
it's
a
it's
a
split
panel,
so
you
can
resize
it
and
I've
built
this
ability
to
toggle,
so
you
can
put
on
the
bottom.
If
you
prefer
these
errors,
we
don't
yet
have
a
way
to
disable
stuffing
into
LA,
but
I
will
soon.
Currently
they
should
all
three
be
disabled.
C
One
is
your
clear
history
and
the
other
is
to
navigate
back
and
forth,
because
details
are
things
you
asked
for
so
I'm
actually
enabled
history
in
this
particular
inspector,
but
you'll
see
that
the
hints
inspector
doesn't
have
those
buttons.
It
just
has
the
toggle
back
and
forth
button,
so
okay,
so
how
does
hints
work
so
right
now?
The
last
thing
I
asked
for
the
result
of
the
last
command
is
still
going
to
show
up.
C
So,
even
though
there's
a
tooltip
footprint
you're
not
going
to
see
it
because
you
explicitly
ask
for
something,
but
if
I
switch
over
I
will
see
it
and
actually,
if
I
go
back
here
and
I
run
one
more
command
now
it's
not
now,
neither
one
of
them
has
fret,
because
details
is
empty.
So
now
you
will
see
any
tool
tip
that
would
have
come
up
and
you
know
slowly
every
any
subsequent
tooltip
really
helpful.
C
Are
things
like
this,
where
I
haven't
even
run
it
yet,
but
I
have
a
lot
of
really
useful
information
that
doesn't
get
in
my
way
this
used
to
be
gigantic.
The
other
is
I
hinted
at
this
before
so
now
in
details
I
do
have
history,
I
can
go
back
to
the
last
thing.
I
looked
at
I
can
go
back
to
this
thing
and
you
know
I
can
clear
my
history
if
I
want,
let's
see
what,
if
you
do,
oh
yeah,
if.
C
D
C
It
runs
oh
yeah,
friends
and
then.
C
So
sorry,
so
that's
that's!
That's
cool
I,
wonder
what
else
to
show
I'm.
So
oh
yeah,
the
other
one
of
the
things
I
want
to
ask
right.
So
so
there
are,
there
are
commands,
or
you
know
doing
that.
Obviously
there's
a
you
can
just
turn
it
off.
If
you
want,
if
you're
just
not
interested
in
it,
there
are
menu
items
just
for
toggling
it,
but
not
switching
this
orientation
because
I
figured
it's
always
gonna
be
easier
to
come
here
anyway.
You
don't
need
three
ways
of
doing
it,
but
two
is
fine.
C
Another
thing
is
that
I
actually
so
I
partly
mod
it
on
this
thing
on
the
actual
developer
tools
in
chrome,
but
so
you'll
see
like
this
is
actually
the
clear
console
same
thing
here,
but
one
thing
I
would
suggest
is
that
we
stopped
using
shift
tab
or
currently
I,
don't
have
a
shift
tab
listener
and
that's
really
useful,
because
if
I'm,
if
I'm
here
in
the
hit
shift,
tab
I
actually
want
to
uninvent,
which
is
what
most
text
editors
do
so
I've
actually
set
my
keyboard
control
for
toggling
this
thing
to
command
I,
because
the
native
browser
one
is
alt
command.
C
C
B
C
C
C
So
we
might
want
to
rotate
inspector
one.
That's
that's
a
good
idea.
C
The
other
thing
is
that
I've
tried
really
hard
to
show
you
the
thing
that
you
expect
to
see
so
it
because
now
there's
no
detail
up
there,
even
though
the
history
still
exists,
because
there's
no
detail
immediately
asked
for
I
think
what
should
happen
if
you
didn't
ask
for
one
is
that
you
should
always
see
the
hints,
but
obviously
you
might
still
want
to
go
back,
and
actually
you
might
be
looking
at
this
and
looking
for
like
inspiration
or
something
and
also
be
like.
Oh
wait.
C
E
So
do
you
render
that's
it
I
I
think
this
is
a
really
cool.
Well,
can
you
keep
sharing
your
screen
and
you
oh
yeah,
yeah?
C
In
fact,
the
toolbar
was
a
later
addition
when
I
realized
I
wanted
more
things
there,
but
about
putting
it
in
the
different
parts
of
the
actual
application.
Shell,
one
of
the
things
is
that
this
console
example
now
also
supports
it.
So
I
have
to
make
it
configurable,
basically
saying:
where
do
you
want
to
attach
this
thing,
whereas
right
now,
there's
a
console
panel
and
it's
self-contained?
So
my
example
page
also
runs
the
same
stuff
without
me,
really
having
to
do
anything
at
all,
but
that's
not
really.
E
I
would
think
that
this
would
be
a
useful
thing
to
show
in
the
notebook
as
well,
while
someone's
tithing
code,
notebook
cell.
So
if
we
had
like
the
shared
shared
instance
of
this
thing
that
showed
just
whatever
you're
typing
it
at
the
time,
whatever
you're
focused
on
that's
basically
sending
messages
to
this
thing,
to
display
tensor
display
details
and
the
person
could
open
it
or
close
it
as
they
want.
Then
it
worked
out
for
all
a
book
type
input.
Oh
so
you
know
another
one.
B
E
D
C
Yeah,
that's
right,
so
you
could
have
groups,
you
could
have
it
associated
with
documents
or
you
could
have
a
beat
well
I
mean
in
the
browser
it's
definitely
associated
with
your
URL.
If
your
URL
changes
you'll
have
the
same
history
but
its
history
like
Calm,
it's
like
this
kind
of
history
console
history.
It's
not
any
I
mean
sort
of
navigable
history,
so
I
think
the
navigable
history
should
probably
be
purged
at
that
point,
but
a.
D
D
So
I'm
wondering
it
if
it's
attached
to
the
actual
documents
themselves
to
the
console
and
individual
notebooks
that
if
someone
has
multiple
consoles
and
notebooks
open
having
all
of
them
have
a
hints
of
details
attached
to
them
is
just
going
to
get
really
busy
and
you'd
guarantee
the
user
would
pretty
much
only
be
able
to
work
on
one
of
those
at
a
time,
and
so
I
do
I,
probably
agree
with
Chris
to
putting
it
in
the
side.
Panel
makes
sense.
The
other.
A
C
D
C
D
E
B
C
The
thing
is
that,
in
terms
of
the
busyness
that
you
might
be
worried
about,
it
all
sits
inside
it
all
sits
inside
your
one
tab
that
you
have
open.
So,
no
matter
how
many
consoles
I
have
open
it's
no
easier
than
it
would
have
been.
If
it's
in
the
sidebar
like
right
now,
I
could
have
one
but
not,
but
it
is
open,
open
holes
right.
C
D
B
E
E
D
That
we've,
that
we've
found
from
working
with
the
existing
notebook
a
lot
is
that
a
lot
of
us
run
the
notebook
in
a
mode
where
pager
output
is
just
fitted
as
regular
output
and
the
part
of
what
we
honestly
part
of
what
we
found
is
that
it's
so
painful
to
lose
vertical
stroll
space
in
a
notebook
and
in
the
column
you
almost
never
want
something.
That's
cutting
down
that
vertical
space,
yeah.
D
C
That's
that
that
time
that
make
sense
what
I
would
what
I
would
ask
or
is
to
have
now
that
there's
a
thing
too
base
decisions
off
of
I
would
ask
for
some
II
quacks
treatment
of
this
and
to
actually
post
specific
behaviors
that
we
want,
because
this
is
this-
is
me
thinking
about
it
for
a
while,
but
I
don't
want
to
be
the
one
who
makes
a
bunch
of
decisions
and
then
receives
a
bunch
of
feedback
and
and
synthesizes
that
feedback
into
a
coherent
thing.
C
B
To
comment
yeah
go
ahead,
sorry
to
two
questions.
One
I
was
gonna:
ask
this
actually
separate
from
Chris,
but
it
seems
like
a
good
point
to
bring
it
up
what
about
making
it
easy
to
drag
stuff
into
and
out
of
the
sidebar.
We
we
had
a
case.
B
C
So
right
we
need
to
make
that
sidebar,
that
side
area
be
dockable
in
the
same
way,
and
another
thing
we
would
do
is
we
would
put.
We
would
pull
in
right
now.
Inspector
is
actually
called
console.
Inspector
and
I
did
that
with
the
intention
of
being
able
to
change
it,
to
be
just
inspector
and
used
by
others
as
well,
and
so
pull
inspector
make
it
first
class
and
have
that
be
a
thing
that
also
resides
in
the
side
area.
I've
made
it
pretty
easy
to
add
new
inspectors.
C
C
So
all
those
things
need
to
be
extensible
and
I,
guess
having
them
extended
in
one
spot
and
having
that
one
thing
just
be
a
first
class
first
class
introspection
tool
that
notebooks
and
consoles
use
is
a
really
helpful
thing
and
if
make
everything,
if
we
make
everything
sort
of
dislodge
able
and
Andrey
dockable,
then
I
guess
you
could
take
a
specific
hint
and
and
lodge
it
somewhere,
but
I
want
to
make
sure
you
can't
take
the
entire
hints
tab.
I.
Think
that
that's
wrong.
C
I
think
we
probably
want
to
take
a
specific
end,
but
I'm
not
sure
this
is.
This
is
the
sort
of
question
that
I
think
we
need
to
resolve.
Basically,
so
I
don't
think
I
would
be
dragging
this
tab.
I
think
I'm
not
sure
I'm
not
sure
actually
so
really
like
who
I
want
to
drag
this
or
do
I
want
to
drag
the
entire
hint
mechanism.
Do
I
want
hints
and
details
to
be
visible
at
the
same
time
like
Brian,
mostly
like
I'm,
not
sure
yeah,.
D
B
D
Ok,
so
my
my
thought
for
now
is
because
this
is
I
think
already
an
improvement
over
existing
treatment
and
master.
Let's
put
the
exact
you,
while
you
have
there
in
the
sidebar,
the
right,
sidebar
merge
it
and
then
once
it's
there,
I
can
have
the
students.
Do
a
design
pass.
Do
some
user
review
to
basically
spend
more
time
on
design
and
I
think
also?
It
will
help
for
all
of
us
to
just
play
with
it
for
a
while
and
sit
with
it
and
see
sort
of
how
it
feels
YUM
and
during.
B
F
C
C
B
F
B
It's
brilliant
cycling
through
it
with
the
arrows
I,
think,
will
quickly
get
boring
or
tedious
and
making
out
a
drop-down
that
just
has
the
just
the
one
word
label,
or
whatever
is,
is,
was
being
looked
up
at
that
point.
Make
it
a
lot
easier
to
scroll
through
those
and
find
the
find
the
details
that
I'm
looking
for
so.
C
Actually,
what
Steve
showed
me
was
the
spider
version
and
that's
exactly
what
spiders
doing
the
thing
is:
I
didn't
know
what
label
should
be?
Should
the
label
be
aight,
?
?,
because
what
if
my
code
looks
like
this.
C
B
C
B
C
C
That
would
be
great,
but
but
without
that
I
don't
have
enough
information.
I.
B
C
B
B
B
B
C
D
Time
we're
trying
to
move
paid
your
output
to
just
regular
output
now
that
the
tooltip
stuff
is
separate
but
but
like
the
ipython
already
has
a
configuration
point
that
reroutes
page
or
output
from
being
a
separate
message,
type
to
just
regular
output.
Okay,
a
lot
of
us
run
ipython
in
that
mode.
We
never
ever
use
the
pager
now,
obviously
I
think
for
feature
parity
until
we
formally
deprecated
the
pager.
We
probably
do
need
to
support
it,
but
your
current
you
I,
would
easily
follow
that
transition
and
not
not
have
a
problem
with
that
that
how.
C
D
I
think
that's
what
we're
finding
is
that,
as
we've
used
the
pager
in
our
current
in
current
implementation,
yeah
there's
a
very
strong
feeling
that
people
don't
want
it
to
be
separate
that
everyone
really
in
part
of
it,
is
that
a
lot
of
us
end
up
writing
documents,
and
we
want
to
show
the
doc
string
in
the
document
that
we're
sharing
with
people
yeah.
And
so
is
it
that's
the
problem.
D
The
pager
output
is
never
included
in
the
document,
and
so,
if
you
want
to
say
now,
let's
look
at
the
doc
string
of
you
know
this
scikit-learn
model,
it's
not
in
the
document
and
I.
Think
that's
one
reason
why
people
are
wanting
to
move
the
pager
from
a
separate
thing
to
do
regular
output,
but
okay,
sort
of
beside
the
point,
because
today
it's
still
like
we
haven't
gotten
rid
of
it
officially
and
we
probably
do
need
to
have
have
some
UI
for
it
all
right.
C
D
And
so
I,
yeah,
I,
think
and
I
think
this
is
going
to
be
the
type
of
thing
that
will
have
to
keep
iterating
on,
but
I
do
think.
This
is
definitely
an
improvement
and
I
think
if
we
move
it
to
this
to
the
right,
sidebar
and
then
merge,
we
can
have
a
designer's
got
to
do
some
UX
work
around
this
still.
C
A
B
B
C
B
G
C
D
D
B
Anything
else
that
we've
seen
a
lot
of
work
I
triage
a
bunch
of
issues.
Sorry,
if
I
triaged
it
wrong,
but
I've
been
trying
to
keep
track
of
what
needs,
work
and
what's
finished
and
with
sprint
friendly,
big
Cal,
Poly,
etc
so
feel
free
to
update
those
are
the
Cal
Poly
students?
Are
they
members
of
the
project?
Can
they
can
they
update
statuses
and
things
like
that.
D
E
E
Internal
implementation
of
the
virtual
Dom,
which
I've
been
toying
around
with
the
idea
of
reviving
a
small
part
of
that
to
help
handle,
provide
a
default
way
of
rendering
leave,
content
or
widgets,
because
everything
Brian
you
mentioned
that
some
of
the
Cal
Poly
students
feedback
was
how
do
I
create
leave
content
until
I?
Don't
think
it's
out
of
out
of
the
purview
of
phosphor
to
provide
some
at
least
default
way
of
doing
that.
So
what
I'm
thinking
about
doing
is
not
changing.
E
How
all
widgets
are
rendered
like
a
widget
will
still
be
a
wrapper
around
Dom
node
that
you
can
provide.
But
if
you
wanted
to
create
a
custom
widget
with
custom
content,
all
you
would
have
to
do
is
reimplement
here
on
update,
request
method
and
render
some
virtual
dog
content
into
that
thing.
So
you
wouldn't
even
need
like
a
dedicated
render
widget.
E
There
would
be
no
components
like
you
get
in
reacts,
basically,
if
you're
anyone's
familiar
with
that
react
to
be
basically
like
pure
functional
components,
if
you
will
like
so
the
stuff
that
you
render
with
a
virtual
Dom,
doesn't
have
any
my
cycle
methods
associated
with
it.
Right,
like
the
lifecycle
method,
is
at
the
granularity
of
a
widget,
and
then
you
can
just
render
whatever
content
you
want.
E
E
And
so,
as
I
move
to
like
try
to
separate
out
or
separate
out
the
common
functionality
of
those
two
things
into
base
class
to
reduce
code
duplication.
Some
I
started
getting
some
questions
about
how
to
define
the
red
or
renderer
for
that
thing
and
whatnot,
and
so,
as
I
was
starting
to
begin
to
this.
E
D
So
a
couple
questions,
so
this
this
virtual
renderer
could
a
widget
that
rendered
its
content
using
that
approach
could
have
a
model
and
it
could
inject
values
from
the
model
into
that
virtual
Dom
tree
and
so
I
mean
literally.
It
could
be
as
simple
as
that.
That
model
has
a
state
change
method
and
it
just
throws
the
model
at
the
virtual,
like
I'm,
trying
to
understand
sort
of
yeah.
D
Correct
closets,
so
we
could
use
that
type
of
data
flow.
The
it
sounds
like
the
main
constraint
that
has
is
that
the
content
rendered
by
one
of
these
widgets
could
not
intermix
virtual
Dom
elements
like
divs
and
spans
and
other
false
religions
correct.
It
would
be
pure,
pure
leaf
content,
yes,
and
so.
D
B
But
so
why
playing
devil's
advocate
you
know,
there's
tons
of
ritual
Dom
libraries
out
there.
Some
are
pretty
small
I
know
that
you
had
done
some
benchmarking
early
on
I
know.
Your
code
was
pretty
decent
early
on
and
everything,
but
devil's
advocate
says
why
why
why
not
use
mithril
ore
view
or
when
some
of
these
other
virtual
Dom
levers
haven't
looked
at
what's
current
this
week,
but
is
it
you.
E
It's
a
bit
another
dependency
which
would
be
larger
than
the
eight
hundred
or
so
lines
that
the
small
virtual
Dom
implementation
is.
So
this
would
keep
foster
self-contained
without
needing
extra
dependencies
and
relying
on
you
know
finding
bugs
and
other
people's
stuff
that
takes
time
to
fix,
and
this
time
the
other
plus
I
already
had
all
the
typing
definitions
exhaustively
pull
down
everybody
in
typescript.
So
we
can
use
all
these
fully
type
safeway
right.
B
D
E
To
the
so,
the
attributes
object
that
you
can
pass
through.
These
virtual
notes
also
includes
time,
save
definitions
for
the
inline
event
listeners,
so
the
simplest
way
to
just
be
at
a
function
from
the
inline
event
listener,
which
you
know
use
a
you
know,
a
fat
arrow
function
which
he
calls
back
into
whatever
you
want.
That's
the
easy
way.
C
E
B
Could
be
interesting
if
we
didn't
fight
the
j
sx
syntax
as
well?
I
don't
even
know
if
I
would
prefer
it
or
not,
but
it'd
be
interesting
experiment
to
see
if
we
could
use
the
typescript
jsx
syntax.
Maybe
people
writing
the
virtual
Dom
widgets
would
really
like
to
use
it
and
it
would
just
compiled
down
to
phosphor
virtual
Dom
instead
of
korea.
E
D
What's
the
model,
so
these
virtual
Dom
nodes
in
the
virtual
Dom
API?
How
do
you
add
classes-
and
this
is
something
that
it's
my
understanding-
that
jsx
has
a
funky
notation
for
adding
classes,
that
it
confuses
a
lot
of
people
and
it'd
be
nice
to
have
a
clean
way
of
adding
classes
to
these
nodes
and
still
yeah
itself?
Oh
sorry!
Go
ahead!
This
yeah.
E
C
E
C
C
E
D
E
I
think
that
all
bets
are
off
and
j
sx
and
terms
of
type
safety,
which
is
one
which
is
one
reason
to
prefer
the
way
that
I've
structured
things
down,
which
is
all
with
typesafe
function,
halls,
which
is
its
and
to
be
clear,
it's
much
better
than
Mike
doing
like
create
element
and
then
passing
in
a
strain
like
there's.
Actually,
a
function
called
in
there's
a
function
called
a
what
not
to
create
these
elements.
So
it's
not.
It's
not
very
onerous
to
write
this
stuff,
oh
and
jas
digs.
D
E
D
B
No,
no
no
yeah
I
was
thinking
optionally
like
it
would
be
interesting
to
see
if
it's
possible,
but
you're
right
about
the
types
it
looks
like
I'm
reading
the
typescript
duck
on
jsx
and
it
says
it's
typed
as
any.
You
can
customize
it,
but
it's
not
possible
to
treat
type
information
about
the
element.
Attributes
your
children.
It's
black
box
literally
says
that
it
is
a
black
box
in
the
doc
stuff.
B
E
E
E
Just
the
same
way,
I'm
going
to
use
regular
Dom
API
to
create
the
skeleton
of
a
tab
bar,
but
we
can
render
the
tabs
themselves
with
virtual
Dom,
because
that
gets
rid
of
all
of
the
dirty
state,
managing
that
I
have
to
do
in
the
top
bar
okay,
so
so
that
kind
of
stuff,
so
that
you'll
see
it
you'll,
see
it
being
selectively
used
within
the
core
widgets.
But
you'll
also
see
me
using
the
regular
Dom
api's
as
well,
when
it
makes
sense.
So
it's
really
just
like
this
is
a
tool
usually
make
sense.
D
The
other
place
where
I've
run
into
this
stuff
is
I'm,
starting
to
think
about
having
a
common
set
of
UI
controls
that
are
like
buttons
and
drop
downs
and
text
input,
areas
and
I
think
that
our
implementation
of
those
we
probably
want
to
be
wits
that
have
signals
that
fire
various
things
but
inside
those
I
think
a
lot
of
these
virtual
rendering
ideas
would
be
really
simple
and
work
really
well.
So.
E
In
this
case,
I
would
say
it
would
be
a
mistake
to
make
a
button.
The
don't
widget,
that's
just
overkill
like
you,
don't
need
that
much
lifetime
lifecycle
management
for
a
button
like
button
can
now
just
become
a
function
that
takes
the
data
model
and
returns
like
a
virtual,
Dom
node,
and
then
anybody
can
use
that
function
call
to
render
a
button
into
their
own
content,
which
it
wherever
they
want.
The
same
thing
with
the
drop-down
like
it
could
just
take
data
structure
or
a
data
model,
and
maybe
some
function.
Callbacks
part.
D
Of
what
part
of
what
of
what
we're
running
into
is
more
sort
of
encapsulating
the
visual
design
of
those
elements,
and
that's
where
having
them
be
widget
classes
allows
us
to
add
all
the
right,
CSS
classes
and
but
I,
don't
know.
I
mean
there's
definitely
think
to
think
about
their
obviously
rendering
a
button
with
a
virtual
dog
makes
no
sense,
especially
because
there's
no
state
there,
but
I
think
there
are
other
stateful
UI
controls
where
the
virtual
Dom
approached
would
would
make
sense
and
simplified
some
things.
Just.
B
I
mean
I
was
a
little
bit
sad
to
see
it
go
and
reading
to
the
Dom
API
and
then
I've
been
having
conversations
with
others
that
are
doing.
You
know
I
leaf
content
in
HTML,
and
even
some
of
the
people
on
J,
hub
and
stuff
like
that.
That
have
been
looking
at
doing
leaf
content
in
HTML
that
it's
a
bit
of
a
pain.
We
all
knew
that,
but
having
a
virtual
Dom,
API
or
something
like
that
would
be
good.
Okay,.
D
Hey
I've
been
like
in
lost
in
administrative
stuff,
or
mostly
complete
geek
I'm
I'm
in
the
process
of
sort
of
meeting
with
the
students
and
we're
going
to
start
to
process
all
the
user,
testing,
stuff
and
sort
of
identify
what
those
students
are
going
to
be
working
on
next.
Based
on
that,
in
the
meantime,
I
think
a
lot
of
them
are
helping
out
and
working
on
different
things.
No,
no
particular
updates
on
what
what's.
Next
with
that,
though,
until
we
go
through
the
user
test
results
more
I.
D
D
D
D
The
command
was
run
and
so
I
myself
and
I've
seen
how
the
user
sit
there
and
keep
pressing
return
and
it
does
the
thing
multiple
times,
and
so
my
and
part
of
the
reason
is
that
the
search
field
is
still
populated
and
the
selected
item
that
you
rent
for
the
command
is
still
selected.
So
my
first
proposal
was:
let's
clear:
the
search
field
and
unser
let
the
command
that
would
run
to.
D
That
something
of
command
was
run.
The
next
is
that,
after
you
run
a
command
your
you
can't
get
back
to
what
you
were
doing
without
using
the
mouse.
So
if
you
are
working
on
a
notebook-
and
you
do
kamancheh
p
to
do
something-
you
can't
keep
typing
in
the
notebook
you
have
to,
let
it
go
back.
Mouse
click,
the
the
notebook
and
so.
E
E
So,
in
the
event
that
the
command
does
change
focus
it
does,
the
command
palette,
doesn't
steal,
focus
back,
which
would
happen
if
it's
that
focus
to
itself
after
the
command
executed,
and
so
so
yeah
we're
retaining
focus
and
selection
on
the
input
field
of
the
command
palette.
In
preparation
in
the
event
that
the
command,
when
it
does
execute
changes,
rose
so
I
think
that's
I
think.
Basically,
the
answer
is
that
we
need
to
be
more
judicious
in
our
setting
of
focus
from
command
execution
handlers,
okay,
but
we
could
clear
the.
E
E
F
One
other
thing
is
that
if
your
command
palette
is
hidden
on
the
style
pressing
the
shortcut
to
get
to
come
and
let
reflow
everything
and
I
would
expect
that,
once
you
execute
something,
you
would
get
back
to
your
initial
review,
because
I
don't,
I
don't
see
any
case
where
user
would
like
to
invoke
a
command
palette
which
is
hidden
and
get
it
get.
Have
it
still
there.
After
what.
F
No,
no,
what
I'm
saying
is:
would
there
be
a
way
to
detect
whether
the
thing
was
like
basically
restores
a
previous
state
like
either?
There
are
two
things:
one:
if
you
have
the
file
browser
and
invoke
the
command
pilot,
when
you
leave
the
command
palette
or
your
Phi
browser
is
gone,
and
the
second
thing
is:
if,
if
the
side
panel
is
completely
hidden,
you
basically
popped
it
up
and
slide
it
back.
So
you
have
a
to
reflow
optional
book.
So
would
there
be
a
way
to
have
a.
B
E
So
we
were
in
the
bin,
the
very
beginning
we
were
debating
whether
to
make
the
plan
pal,
like
a
temporary
thing
that
drops
down.
Consider
we'll
make
it
a
sidebar
item
that
kind
of
pops
out
from
Oz
back
in
and
I
kind
of
voted
for
the
sidebar
one,
because
I
don't
like
how
sublime
when
I'm
doing
the
command
palette
like
blocks
the
text,
I'm
looking
at
because
oftentimes
the
command
that
I'm
looking
for
is
related
to
the
text
that
I'm
typing,
and
so
by
opening
over
by
text.
E
Now
I'm
like
what
text
I'm
out
and
so
that's
why
I
went
for
something
for
the
sidebar.
But
again
it's
it's
six
of
one
half
dozen,
the
other.
Clearly,
some
people
don't
like
the
sidebar
approach
or
they'd
rather
have
the
drop
down.
So
maybe
maybe
the
conversation
we
should
be
having
its
whether
the
command
palette
is
really
ephemeral.
Enough
that
you
know
a
drop
down
is
the
right
way
to
do
it
and
like
I'll,
just
be
in
the
minority
of
people
where
I
deal
with
the
covering
my
text,
but.
B
F
That,
if
the
command
palette
is
already
shown,
it's
perfectly
good
like
if
someone
have
a
sidebar
wooden
pallet
having
control
ships
p.
Focusing
this
one
is
a
perfect,
reasonable
things
to
do,
because
it's
already
there
and
it
won't
be
through
the
thing
is
that
annoys
me
is
if
the
commonality
is
not
already
visible.
So
we
could
have
cuddle
shh
p
that
there's
a
slightly
different
action
depending
on
whether
as
a
side
problem
is
already
there
or
not.
There
yeah.
D
D
D
At
the
results
of
your
tests,
I
guess
I
think
my
is
not
obvious
to
me
I'm
right
now,
probably
5050
on
sidebar
vs
modal
drop-down
style
command
palette.
My
thought
is
that,
like,
let's
improve
what
we
have
now
and
I
think
we
can
make
a
few
very
small
changes
to
the
interaction
and
see
if
it's
good
enough
and
keep
iterating.
The
two
big
changes.
I
think
we
should
make,
though,
is
that
command
shift.
D
P
is
currently
tied
to
the
toggle
command,
and
so
if
the
command
palette
is
already
open
and
you
do
command
shift
p,
it
collapses
it
totally
weird,
it
should
be
activate
rather
than
toggle
and
the
other
is
that
I
think
we
should
clear
the
search
field
when
the
command
is
run.
So
user
knows
that
they
ran
a
command
and
five
like:
let's
do
those
two
things
and
see
if
it
improves
and
if
not
keep
iterating.
Looking.
B
H
Just
you
know,
as
a
casual
user
I
would
leave
the
command
palette.
Open
I
have
the
real
estate
on
the
screen
to
do
so
so
I.
Don't.
H
B
F
H
F
Yes,
I
think
if
it's,
if
it's
open
right
now,
except
the
publisher
and
raise
that
it
actually
toggle
the
command
palette,
there
is
no
issue
and
the
issue
paper
that
actually
wants
it
to
be
hidden.
We
need
to
find
a
slightly
more
sensible,
behavior
I
think
it's
perfectly
following.
If
we
don't
fix
that
right
now,
but
the
like
one
point:
0
and
4
for
some
workflow
I
think
it's
important
to
to
not
not
reflow
and
have
something
which
is
more
out
of
your
way.
I.
B
F
To
remember,
can
we
get?
Is
there
a
way
to
I
guess
I
guess
there
is
a
way
to
replace
the
command
palette
by
owners
are
freaking,
so
it
might
be
a
question
of
actually
our
implementation
will
be
the
default
and
say
hey.
You
want
something
which
is
really
more
like
likes
or
more
sublime,
like
afraid,
I.
B
G
B
Just
a
note
on
the
so
I
attack,
lots
of
things
need
discussion.
If
you
want
to
discuss
things
or
jump
into
some
of
the
discussions
that
are
happening.
Look
at
the
issues
if
I
tagged,
a
lot
of
things
has
helped
wanted
anything.
It
didn't
look
like
somebody
was
actively
working
on
it.
I.
Thank
this
help
wanted.
So
there
might
be
a
cue
list
for
Cal,
Poly
and
and
anyway
so
there's
two
places
to
look
for
places
that
need
feedback
or
deep
discussion
to
keep
things
living.
E
F
B
More
or
view
so
I'm
planning
on
giving
essentially
that
talk
or
an
updated
version
of
that
takut,
my
dad
a
DC
in
the
second
week
of
October,
so
October
73
rates
or
something
like
that
and
then
of
course,
we
have
strata
coming
up
at
the
end
of
sep
tember,
where
we
plan
on
giving
some
sort
of
Jupiter
lab
type
talk.
So
I
guess
we'll
keep
updating
that
talking.
The
materials
are
out,
but
we
should
put
more
polished
materials
up,
for
whoever
else
is
giving
a
talk.
That
wants
to
talk
about.
Jupiter
luck,
I'll.
G
G
At
Jupiter
days,
Atlanta
understand
date,
given
the
same
talk:
okay,.