►
From YouTube: YUI Open Roundtable 01/31/2013
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
C
So
tree,
which
is
a
just
a
low-level
tree
data
structure
with
no
UI
to
it,
is
in
the
gallery
and
it's
on
the
CDN
and
that's
what's
used
for
swung
bugs
tree
view
gallery.
Module
2,
which
is
also
on
the
CDN
and
menu,
is
another
gallery
module
that
that
we're
using
a
smug
mug,
but
we
haven't
yet
published
to
the
gallery.
Just
because
I
was
telling
tea,
though
I
haven't
had
time
to
write,
docks
were
yet
and
it
also
uses
tree
into
the
hood.
C
A
We
have.
First
item
is
very
demos.
I've
been
this.
Is
that
basically,
a
request
for
me
to
you
guys
guys
if
you're
watching
this
to
come
up
with
the
demos,
give
something
interesting
if
using,
why?
Why
do
you
want
to
walk
here?
Please
come
online
with
us.
Roundtable
show
off
your
stuff
is,
if
you
want
heavy
demos,
I
want
to
show
over
him.
A
C
On
you
see.
C
Yeah,
so
it's
just
a
basic
menu,
you've
got
sub
menus
and
whatnot
headings
and
separators,
and
you
know,
drop
downs
and
everything.
So
this
is
all
pretty
standard,
but
the
cool
thing
that
it
does
is.
First
of
all,
you
can
build
this
all
from
script,
which
node
many
knife
can
do
right
now
and
t.
Lo
yesterday
said
you
wanted
to
be
able
to
build
it
from
mark
up
to
so
I
implemented
that
so
that's
there
too,
but
the
really
cool
thing
it
does.
Is
it
intelligently
constrains
your
menus
to
the
viewport?
C
So
right
now
you
see
I've
got
this
menu
all
the
way
over
on
the
right
of
the
screen,
and
normally
this
would
open
out
to
the
right.
But
it
detects
that
you
know
the
viewport
ends
there,
and
so
it
figures
out
the
best
alternate
position
for
it,
and
then
it
keeps
cascading
these
things
down
to
the
left.
Since
that
were
started
going,
and
you
know
if
I
move
it
to
the
bottom,
then
after
a
certain
point,
it
realizes
it's
running
out
of
space
at
the
bottom,
so
it
pops
it
up
to
the
top.
C
So
under
the
hood
you
know
a
menu
is
basically
just
a
tree.
It's
got,
you
know
a
bunch
of
top-level
items
and
then
each
item
can
contain
more
items,
so
the
menu
itself
is
a
tree.
And
then
each
item
is
a
node
in
that
tree
and
submenus
are
just
you
know,
nodes
underneath
out
of
your
nodes,
so
yeah
the
data
structure
under
the
hood
is
the
same.
D
So
I've
been
I've
been
using
ryans
menu
and
I'm,
basically
trying
to
for
our
for
our
CSS
stuff
trying
to
get
it
so
that
I
can
kind
of
separate
some
of
the
CSS
well
right
now.
I'm
just
trying
to
get
horizontal
menu
is
working
well.
So
right-
and
I
were
just
talking
about
that-
but
you
were
going
to
be-
can
we
can
then
use
the
same
code
for
something
like
nav
bars
and
get
rid
of
node
men?
D
You
have
and
and
then
use
it
for
drop
downs
and
horizontal
menus
as
well
and
bring
it
together
for,
like
the
CSS
/
javascript
stuff
over
that
we're
bringing
to
make
it
easy
for
people
to
rapidly
prototype
stuff.
A
G
You
want
to
I
just
put
my
name
down
in
case
other
guys,
weren't
here,
but
since
they're
here
I
think
I
should
just
attacking,
listen
well.
H
So
this
popped
up
in
RC
earlier
this
week,
man,
I
was
doing
sucks
reality
and
I
had
a
bunch
of
tickets
that
were
cited
Mia
for
both
know,
minitab
and
if
he
inter-allied
and
beliefs
ova,
it
was
yeah,
so
those
are
assigned
to
me
but
I.
It's
not
even
close
to
one
of
my
priorities
at
this
point
with
other
stuff
going
on
and
there's
been
so
little
development
that
has
occurred
on
the
module
and
some
others,
and
we
have
a
number
of
outstanding
bugs
with
them
it's
kind
of
like
do.
H
We
just
accept
the
reality
that
these
arms
they're
supported
and
good
quality,
but
they're
basically
abandoned
at
this
point.
So
I
would.
C
G
C
Well,
I
can
I
can
tell
you
from
my
experience,
like
the
reason
that
I
built
a
different
menu
component
instead
of
just
going
with
the
node.
Many
nav
is
that
I
looked
at
know
many
nav
and
saw
all
the
things
that
would
need
to
be
fixed
and
all
of
the
ways
that
it
worked.
That
I
didn't
want
it
to
work
and
would
have
to
be
changed
and
it
ended
up
being
a
lot
less
costly
in
terms
of
my
time
to
just
build
it
fresh
and
I.
D
G
C
G
I
C
Does
raise
the
question
of
do
we
need
a
viable
alternative?
I
mean
we
have
white
up
menu.
You
know
the
the
gallery.
Module
I've
been
working
on
to
be
happy
to
contribute
it,
but
I
think
Eric
actually
raised
a
good
point
in
IRC,
which
is
maybe
the
tree
data
structure
should
go
in
because
that's
really
generally
useful
in
kora
now.
C
G
Area
because
we
I
think
internally
I,
don't
know
how
much
of
this
is
visible
externally,
but
we
have
started
really
talking
about
core
versus
gallery
and
beefing
up
the
gallery
to
house
a
lot
more
of
what's
in
court
today
and
where
this
gray
area,
where
we're
not
quite
there
yet
so
in
the
future.
We
think
that,
like
our
vision.
E
G
That
at
the
the
leaf
level,
widget
should
live
in
gallery.
But
if
the
underlying
core
infrastructure
pieces,
like
the
widget
module
and
why
not
treat
those
things
should
live
in
core
but
that'd
be
out
lying,
why
not
data
table
or
why
not
menu
should
live
in
the
gallery.
So
that
is
the
vision
and
I
think
that
it's
getting
a
lot
of
traction,
it's
starting
to
make
a
lot
of
sense.
G
But
since
we're
not
there,
yet
you
know
what
do
we
do
with
with
with
white
up
menu
today
and
I
say
we
follow
the
structure
that
exists
today.
If
we're
going
to
decide
today
whether
why
not
manisha
live
in
gallery
or
core,
it
should
live
in
core,
because
we
haven't
really
made
that
migration
yeah
and
then.
H
G
G
C
It
isn't
something
that
it
has
been
on
my
primary
plate
for
a
couple
of
weeks
now,
I
just
kind
of
came
back
to
it
when
tila
started
using
it
and
giving
me
feedback
so
I
could
I
could
plan
on
getting
back
to
it.
I
think
there
are
things
before
it
was
before
it
goes
into
core
right.
I
would
want
to
finish
keyboard
support.
C
And
a
related
thing
would
be
if,
if
I'm
going
to
build
keyboard,
support
for
this
I
want
to
build
a
replacement
for
node
focus
manager
as
well,
and
it's
kind
of
in
the
same
boat
as
many
now
it's
it's
there,
they're
actually
just
completely
tied
together,
they're
they're.
Both
you
know
really
old
and
kind
of
broken
and
need
a
lot
of
work.
J
Yeah,
I
think
the
the
best
thing
that
I
would
like
to
do
is
to
start
the
deprecation
process
for
those.
Now
that
way,
we've
got
a
couple
of
releases
to
get
the
others
in
in
place.
So
we're
telling
everybody
that
we
are
going
to
deprecate
it,
but
it
still
stays
in
the
in
the
library
for
at
least
a
couple
of
releases.
J
If
tree
is
ready,
you
know
Brian
think
street
is
ready.
Then
I
would
like
to
pull
that
into
core,
so
we
can
start
getting
it
in
place
and
see
other
parts
of
the
the
library
that
could
actually
use
it
yeah
and
then
and
then
work
toward
getting
the
other
ones
in
in
small
ways,
because
I
mean
we're
going
faster
cycle,
so
the
sooner
we
can
get
them
in
the
better.
We
can
get
them
in
and
get
them
integrated,
get
them
up
and
running
and
then
just
start
layering.
On
top
of
that,
as
we
go
yeah.
C
G
That's
cool
too
Daniel
I
think
we
should
take
if
we
have
mutual
level
of
consensus.
Yeah
I
think
we
should
take
this
discussion
to
the
mailing
list
and
just
do
that
formal
vote
and
get
the
Plus
Ones
and
have
it
scanned
for
posterity
that
this
is
our
decision.
Does
anyone
want
to
raise
their
hands
to
write
those
emails?
I.
J
J
A
C
A
J
So
right
now
in
the
library
we
have
basically
two
pseudo
kind
of
sort
of
feature
test
things
that
aren't
really
feature
tests.
Most
of
our
feature
tests
are
actually
conditional
modules
in
loader
to
determine
what
module
we
load
based
on
a
some
kind
of
a
condition
or
most
of
them
are
featured
feature
tests.
We
have
a
couple
of
places
in
the
library
that
we
use
simple
feature
tests,
but
we
don't
have
a
really
good
solid
place
to
put
them.
J
What
my
my
initial
thought
on
this
is
I,
actually
have
it
written
up,
I
just
haven't
posted
up
and
a
guest,
yet
I'll
get
that
up
here
after
this
is
it.
I
would
like
to
move.
Wideout
features
to
Yui
dot
features
make
it
a
static
off
the
global,
take
away
the
auto
naming
of
the
little
number
things
and
actually
make
them
nameable.
So
you
could
say
y
dot,
yui
dot
features
dot,
something
foo
and
it
would
return
whether
that
feature
task,
pastor
failed.
J
That
way,
we
could
not
only
name
these
things,
so
we
could
share
them
because
we
actually
have
a
couple
of
them
that
we've
had
to
move
around
to
share
feature
test
between
modules,
but
also
so
we
don't
ever
have
to
compute
them
again
because,
like
right
now
we
have
y
dot
features
and
each
one
of
those
feature
test.
Sorry
run
every
time.
We
create
an
instance
and
that
sucks.
J
So
I'd
like
to
move
those
out
into
the
static
off
of
Yui
that
way
that
they're
they're
always
accessible
from
everywhere
and
they're,
shared
across
all
the
instances
and
then
make
y
dot
feature
just
mimic.
Your
just
passed
back
through
to
Yui
not
feature
that
way.
You
can
still
use
it
locally,
but
I
don't
really
see
a
reason
why
feature
tests
should
have
to
be
scoped
to
an
instance
because
you're
an
instance
is
running.
You
know,
you've
got
five
instances
on
the
page.
J
A
rate
up
for
each
is
not
going
to
change
between
one
of
the
other
one.
You
know.
So
we
automatically
know
where
we're
living
at
that
point.
So
I
want
a
little
bit
of
feedback
off
that
see
what
everybody
else
thought
before
I
write
the
rest
of
it
up.
Unfortunately,
that
means
it's
going
to
be.
There
could
possibly
be
a
breaking
change
somewhere
to
people
if
anybody's
relying
on
white
up
features
by.
J
The
fundamentally
under
the
hood
they're
going
to
have
to
change
because
the
way
that
they
are
now
is
they
they're
programmatically
generated,
and
the
name
of
it
isn't
is
a
number.
So
it
starts
at
zero
and
it
runs
up,
and
then
they
have
these
weird
categories
that
I
still
haven't
figured
out.
Why
and
wanted.
J
That's
going
to
speed
those
things
up,
really
really
big
and
should
give
loader
or
bigger
performance
hit
or
performance
boost
as
well,
because
every
time
you
create
a
new
instance,
loader
has
to
go
through
and
do
all
those
feature
tests
again.
So
if
you
do
two
instances
back-to-back
both
of
them
requiring
DD
loader
is
going
to
run
through
all
of
Dedes
feature
test
or
even
worse
charts.
J
B
J
So
what
I'm
trying
to
do
is
I'm
trying
to
figure
out
the
right
way
to
do
it,
because,
right
now
we
keep
all
of
that
stuff
in
loader,
metadata
and
people.
Don't
really
know
what
feature
tests
are
there,
so
some
people
might
actually
be
writing
duplicate
tests
and
not
realize
that
they're
writing
a
test.
Somebody
else
is
already
written,
so
what
I
want
to
try
to
do
is
figure
out
the
best
place
to
put
that
information,
the
best
way
for
us
to
name
it
and
then
how
do
they
get
built
and
consolidated?
J
Because
all
of
this
stuff
has
to
live
in
the
seat
in
order
for
these
tests
to
be
functional,
but
they
need
to
live
somewhere
else.
So
people
know
where
they're
writing
their
tests.
So
do
we
keep
the
feature
test
with
the
module
or
do
we
create
an
actual
features,
module
that
that's
where
everybody
goes
in
and
puts
all
of
their
feature
tests?
The
only
problem
with
that
is
is
when
you
get
into
the
gallery
and
we
start
12
mix
at
people's
external
features.
How
do
we
handle
that
as
well?
J
How
do
we
pull
in
their
features?
To
be
able
to
build
their
own
custom
seed
with
their
own
feature,
tests
or
whatever
so
I
still
have
to
figure
all
of
that
out,
but
I
wanted
to
make
sure
it
got
in
everybody's
head
that
way.
When
I
start
writing
this
up,
we
can
have
the
big
discussion
on
all
these
little
fine
pieces.
J
H
Yeah
they
can
makes
a
lot
of
sense.
You
know
I
definitely
can't
think
of
a
reason
why
we
need
instance
different
instances
of
that
data
and
cashing.
It
seems
like
a
really
good
idea,
so
yeah.
J
Well,
the
only
the
only
time
I
could
see
needing
any
kind
of
instance
base
is.
If
it's
browser
string.
You
know
anybody
check
in
user
agent
strings
for
stuff,
because
on
the
server
people
might
need
to
run
through
some
of
those.
So
we
kind
of
have
a
double
classification
on
the
features
and
I
got
it.
J
We
have
to
try
to
figure
out
the
best
way
to
handle
it,
because
we
have
quite
a
few
conditional
modules
that
just
ping
off
of
the
user
agent
and
those
are
handy
on
the
server,
especially
when
loader
is
being
used
on
the
server
to
generate
dependencies
for
a
page.
People
can
take
the
you
a
string
and
they
can
toss
it
into
the
way.
I
instance
an
actual
get
the
feeder
the
the
feature
test
out
of
loader
in
order
to
serve
the
proper
thing
back
to
the
client.
J
But
then
there's
also
the
the
caveat
that
what
we
want.
You
know
what
I
want
to
do
is
I
want
to
take
all
of
those
out
on
the
server.
So
it
does
bare
minimum
calculation
and
then
loader
on
the
client
fixes
the
rest
of
it.
So
there's
a
bunch
of
catch-22
s
and
that's
what
I'm
trying
to
figure
out
as
the
best
way
for
us
to
do
it
that
encompasses
everything
that
we
want.
Would
you
have
a
way
to
override
it
as
you.
J
J
J
Theoretically,
we
could,
but
the
the
whole
point
is
those
I
don't
want
to
tailor
what
we
do
on
the
client
just
for
the
server.
I
want
to
make
sure
that
I've
got
something
that
works
in
both
situations:
I'm,
actually
leaning
more
toward
the
don't
execute
any
conditional
feature
modules
on
the
server
and
just
give
back
the
bare
minimum.
But
we
have
a
problem
with
that
in
a
couple
of
our
modules,
actually
like
some
of
the
the
node
modules
for
y
note,
some
of
those
modules
assume
that,
if
something
doesn't
happen,
then
it's
IE.
J
So
if
the
feature
test
fails,
then
it's
IE
and
it's
always
going
to
fail
on
the
server.
So
when
we
do
the
generation
on
the
server
we're
always
getting
I
ebay,
stuff
inside
of
the
node
and
I
want
to
take
those
and
switch
them
the
other
way
so
that
they
don't
require
that
by
hand,
and
they
have
to
pass
a
feature
test.
Two.
It's
actually
load
the
module
that
way
we
can
safely
on
the
server
generate.
J
J
That's
where
I
was
saying
is
that
we
could
have
a
way
to
prep
those
feature
test.
So
my
idea
for
that
was
being
able
to
like
load
a
developer
page
or
something
on
the
device
that
you're
wanting
and
it
would
go
through
and
tell
you
what
feature
test
passed.
So
it
would
give
you
these
are
them.
These
are
the
nine
pre
named
feature
tests
that
have
passed.
Here's
your
object,
configuration
put
that
into
loader
and
loader
will
do
the
right
thing.
Mm-Hmm.
E
J
J
G
J
The
the
big
thing
is
is
changing
him
to
names.
So
in
my
in
my
opinion,
the
original
features
were
written
specifically
around
RLS
and
they
were
trying
to
do
the
number
two
number
pass
that
to
the
server
and
the
server
has
the
same
numbered
feature
feature
test,
but
in
the
real
world
that
doesn't
work
because
every
time
somebody
changes
something
those
numbers
mean
nothing.
Those
numbers
are
pointless,
so
I
wanted
to
go
to
names.
J
J
J
You
can
put
that
in
as
the
condition
and
trigger
it
by
that
name,
and
it's
just
loaders
just
going
to
do
the
right
thing
and
run
only
if
that
condition
is
met
and
and
then
that
also
gives
us
the
ability
to
create
a
config
file.
So
somebody
can
create
a
config
that
says
named
true
name:
false
name,
true
name,
false
pass,
that
into
loader,
and
it's
still
going
to
do
the
right
thing
and
then
programmatic
wise.
For
us
we
get
to
name
them,
something
that's
appropriate.
We
know
what
this
name
means.
It
says
something
it.
A
J
So
I'm
going
to
go
through
and
put
my
notes
up.
I'll
either.
Do
it
today
or
tomorrow
to
finish
out
everything
it's
in
my
head
and
then
once
I
do
I'll
put
it
up
on
the
mailing
list
and
then
maybe
we
can
have
a
hangout
to
discuss
it.
If
I
have
some
pseudocode
or
some
something
to
document
it
em.
But
what
I'm,
trying
to
what
I'm,
really
trying
to
figure
out
more
is
what
all
this
is
going
to
break.
J
When
I
change
this,
so
I
know
how
how
hard
it's
going
to
be
to
actually
implement
it,
because
not
only
do
this
code
in
the
core
have
to
deal
with
it,
but
developers
have
to
be
taught
and
a
build
has
to
be
generated
to
be
able
to
generate
the
mash-up
of
this
stuff.
So
I
have
to
figure
out
the
right
ways
to
put
plate
things
and
how
people
do
it.
You
know
more
likely
there'll
be
a
yogi
command
that
lists
all
the
features
that
way
you
can
see.
J
Well,
I,
don't
want
to
name
spacing,
because
theoretically,
they
should
not
be
module
specific,
they
should
be
function
specific.
They
should
be.
Do
I
need
this
for
a
reason,
not
this
module
I
mean
we
moved
somewhat
to
that,
with
the
touch
enabled
that
we
did.
We
actually
move
that
over
into
you
a
because
we
had
so
many
places.
It
was
actually
looking
for
that,
but
I
want
to
get
even
more
specific
and
more
fine-grained
with
it
to
say
what
all
these
things
are
and
then
I
also
don't
want
to
have
them
all
execute
up
front.
A
J
A
J
J
Right
so
yeah
we
could.
Theoretically,
as
we
get
these,
we
could
start
having
names
for
the
the
groups
of
these
things.
We
can
actually
have
JSON
file
sitting
in
there.
That
says
this
is
a
WebKit
only.
This
is
a
Firefox
only
you
know
this
is
this
is
for
Firefox
OS.
You
plug
this
in,
and
this
thing
is
guaranteed
to
run
on
firefox
OS,
because
all
the
dependencies
have
been
met.
A
J
Yeah
you
know
I
started
thinking
about
when
I
was
actually
I
was
profiling,
instance,
creation
and
instance.
Creation
is
actually
really
really
fast,
because
it's
not
doing
anything,
it's
the
second.
You
do
a
dot
use,
that's
when
everything
goes
to
hell,
but
what
the
only
thing
that
bubbled
up
to
in
the
reason,
I
started
looking
at
it
was
CEO.
The
only
thing
that
bubbled
up
an
instant
secretion
was
actually
wide
array
and
y
dot
object.
J
Has
all
those
checks
for
a
raid
out
for
each
and
object
keys
that
it
executes
every
single
time
an
instance
is
created
because
the
because
of
the
y
dot
add
that's
being
recalled
every
single
time.
So
it's
doing
a
local
module
cache
of
that,
but
it's
not
doing
a
global
cache.
So
that's
why
I
started
thinking
of
moving
these
things
up
into
the
global
Yui.
That
way,
they're
always
cached.
All
the
time
never
run
more
than
once,
and
we
should
see
a
significant
improvement
in
just
those
pieces.
J
C
I
think
that
I
was
thinking
about
that
night
and
I
think
we
probably
don't
need
to
worry
about
it
because
it
would
have
to
be
like
initially
when
we
calculate
our
features.
They
haven't
broken
anything,
so
it
all
works
and
then
later
at
some
point
they
break
something.
So
then
our
features
are
no
longer
accurate,
but
I
think,
if
you're
going
to
do
that,
you're
going
to
be
that
crazy
and
you're
going
to
break
a
native
biota
type.
You
deserve
whatever
you
get,
yeah
yeah.
C
So
if
we
have
like
a
real
problem
area
like
I,
think
the
one
that
I
wrote
it
for
in
the
library
was
Twitter
had
some
some
j/s
that
was
over
writing
like
really
weird
stuff
that
it
didn't
need
to
override.
It
was
breaking
it,
and
that
was
a
very
specific
case
that
I
knew
this
thing
breaks.
When
Twitter
does
this,
and
so
it
made
sense
to
pay
that
cost
of
run
time
to
check
that.
J
Well,
yeah
that
if
I
build
it,
you
know
by
putting
the
you
know
those
all
those
feature
results
in
an
object.
Hash,
that's
actually
an
underscore
property
of
Yui,
not
features
they
can
just
go
in
there
and
say
why
do
I
top
features,
dot,
underscore
tests
or
results
equals
curly
braces
done,
the
entire
cache
is
wiped,
it'll
run
it
all
over
again.
H
J
H
J
But
but
the
other
reason
I
was
looking
at
that
too,
is
that
on
the
server
we
could
actually
null
that
out,
so
that
there
are
no
feature
tests
on
the
server.
So
when
it
loads
up
a
node,
Yui
dot
features
that
underscore
results.
Bam
done,
they're
all
gone,
no
feature
tests
happen.
So
then
you
can
you're
good
to
calculate
dependencies,
because
then
everything
comes
back
false.
J
A
J
Exactly
and
if
we
can
do
it
right,
the
other
good
thing
about
it
being
global
is
that
you
could
actually
modify
those
feature
tests
on
your
own
by
including
your
script
right
after
hours.
So
if
you
had
a
javascript
file,
you
can
actually
put
y
UI
features,
dot,
add
feature
with
a
name,
and
you
know
four
or
five
of
them
and
just
can
katom
in
right,
underneath
our
seed
and
your
feature
tests
are
already
available,
so
they
work
the
same
way.
A
A
It's
there
and
for
those
of
you
online,
if
you
go
to
the
Round
Table
Topics,
wiki
page,
to
be
able
to
find
those
links,
so
we'll
just
jump
into
those
for
the
first
open
request
that
has
been
updated
for
a
while
we're
actually
getting
really
good.
This
we
used
to
have
when
we
started
this
off.
We
had
poor
requests
that
were
six
months
old
or
older,
and
now
the
oldest
in
terms
of
being
updated,
is
17
days.
A
F
C
Thing
that
you
could
do
I
mean
you.
Can
it's
not
super
easy,
because
github
is
a
little
weird,
but
now
that
we
have
issues
enabled
you
can
find
the
pull
request
in
the
issues
and
actually
give
it
labels?
So
if
you
wanted
to
say
you
know
this,
this
thing
we're
not
ignoring
it.
It's
just
you
know.
A
long
term
is
going.
It's.
G
A
A
A
A
A
C
Think
that's
still
a
work
in
progress.
I
know
he's
been.
He
just
had
some
j's
perf
numbers
related
to
that.
The
other
day
I
think
he's
still
working
on
stuff.
Also.
G
A
G
A
lot
of
times,
someone
that
you
know,
submit
a
pull
request
to
a
component
that
isn't
an
active
development.
So
don't
really
feel
ownership
to
like
take
a
look
at
it
that
those
tips
were
the
ones
that
were
tending
to
fall
through
the
gaps.
So
those
would
be
good
to
bring
up
to
the
group
and
horse
eyeballs
on
them,
and
it's.
A
C
This
one
this
was
the
the
bind
change
and
Dave
pointed
out
that
none
of
the
proposed
changes
like
we
arrived
a
change
that
the
code
I
think
everybody
was
happy
with
them.
Dave
did
performance
tests
and
the
performance
is
a
lot
worse
than
what's
currently
there.
So
I
think
the
sounds
like
that's.
A
minus
one
performance
is
too
bad.
J
Yeah
that
and
Adam
actually
brought
up
the
good
point
of
the
the
string
method
is
used
a
lot
and
that
they
removed
that.
So
though
one
if
that's
a
major
breaking
change
and
to
the
performance
was
just
way,
subpar
I
mean
we're
talking
nine
ten
times
slower,
so
I,
just
I
I
left
it
at
that
because
they
were.
J
You
know
there
are
some
people
chiming
in
to
see
if
they
could
work
on
it,
and
nobody
has
given
me
a
good,
a
good
new
one,
so
I've
just
got
to
let
it
sit
there
and
let
them
figure
it
out
on
their
own
I'm,
not
really
sure
what
we
want
to
do
with
it.
There's
no
way
I'm
merging
it,
because
right
now
it
would
break
a
lot
of
things
and
it
performance
would
just
blow
out
the
doors
with
it.
I
think.
E
F
C
F
C
Anstead
this
when
I
came
in
just
cuz,
it
said
focus
manager,
and
it's
one
of
those
things
like
it
seems
like
a
good
fix,
but
the
fact
that
it
was
needed
at
all
like
the
fact
that
focus
manager
uses
event
simulation
for
its
core
functionality
speaks
to
why
I
think
focus
manager
needs
to
be
deprecated
well.
A
C
C
G
A
A
H
Being
there
so,
oh
you
so
the
perhaps
it
was
an
incorrect
assumption.
I
thought
that's
what
the
new
unassigned
user
was
for
resemble.
Oh
and
this
pendant,
but
we
want
to
do,
is
tell
me
to
hate
these
really
awesome,
yeah
yeah.
So
we
have
a
user
that
we
have
at
the
track.
What
I
don't
know
about
two
months
ago?
It
seems
like
called
on
the
side,
so
these
are
bugs
that
are
firm.
They
don
assigned
any
developers
either
internally
or
externally.
H
This
is
what
kicked
off
the
entire
discussion
about
no
main
focus
manager
is
that
those
two
are
technically
assigned
or
that
those
two
components
you
technically
assign
to
me,
but
it's
just
not
on
my
plate
that
also
reset
those
two
other
side
and
then
yeah
valid
we've
announced
that
we
were
probably
deprecated
both
of
them
I.
Don't
think
anybody
will
pick
them
up,
but
if
you
are
it's
you
to
start
working
on
something
before
so
that's
my
question.
A
G
C
H
G
G
F
A
C
H
We
probably
should
go
through
and
do
another
check
on
component
ownership
and
just
to
see
now
that
what
is
we're
trying
to
open
up
the
contribution
process,
a
lot
more
yeah,
so
things
things
like
console
and
slider
is
slightly
I.
Think
sluggers
mine,
but
apparently
there
are
sometimes
perfect-
is
showing
it
by
the
list.
Yes,
I
console
is
mine,
but
again
that's
not
I.
There's
no
critical
bugs
that
I'm
aware
of
been
so
any
of
the
low-hanging
fruit.