►
From YouTube: 2021/12/30 - Backdrop Design/UX Meeting
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).
A
C
Hi,
I'm
greg
I'm
joining
from
greece
generally
interested
in
anything
related
to
backdrop
and
trying
to
get
some
things
fixed
or
features
getting
in
for
the
next
release
excited
about
that.
I
can't
keep
up
with
the
community
anymore.
D
I
had
big
plans
for
getting
stuff
done
this
week
that
family
and
holidays
have
all
kind
of
crushed,
so
we'll
see
what
we
can
do
in
the
last
few
days.
We've
gotta
go
feature
freeze
in
a
couple
of
days.
So
that's
all
of
us.
Let's
go
ahead
and
just
sort
of
jump
into
the
meeting.
D
D
I
haven't
put
much
thought
into
the
the
agenda,
but
I
know
that
we
have
sounds
like
greg
and
robert,
hopefully
have
some
some
agenda
items
we're
getting
joined
by
wilbur.
I
will
burp
do
we?
Could
we
just
dive
into
issues
one
at
a
time
or
do
I
want
to
list
a
couple
quick?
Is
there
a
couple
we
were
talking
about
token
filter?
A
Dev
meeting,
rather
than
that,
unless
it
was
whether
to
put
it
on
v.org
and
that's
sort
of
our
our
external
face,
so
b.org
questions
often
seem
to
show
up
in
the
outreach
meeting
next
week.
It
would
be
great
to
get
an
answer
from
the
dev
folks.
D
Wow,
yes,
so
I
so
the
the
outreach
meeting
would
be
next
week.
Does
anybody
have
any
objections?
That's
putting
tokenfilter
on
v.org,
along
with
the
the
module
to
dynamically
display
dates
based
on
user's
browser.
C
C
D
To
get
jen
involved
in
that
discussion,
we'll
see
if
she
shows
up
at
the
next
meeting,
but
he's
not
been
around
much
lately
robert,
I
would
say
if
we
don't
hear
otherwise
today,
I
don't
think
there's
any
reason
we
need
to
hold
off
on
that.
I
think
we
could
just
go
ahead
and
do
it.
It's
not
it's
totally
reversible
if
there's
a
problem
right
yep.
So
I
wouldn't.
I
wouldn't
delay
this
too
much
longer.
Okay,.
D
There
is,
or
what
else
we
were,
we
had
started
to
talk
about
right
before
the
meeting.
Well,
no,
that
was
okay.
The
the
reissue
robert
you
had
brought
up.
Was
this
one?
So
we're
gonna
pick
that
can
down
the
road
right?
You
had
an
issue.
C
Yeah
it's
hard
to
explain.
I
tried
this
to
sort
of
like
I
started
putting
it
all
in
a
draft
issue
that
I
was
creating,
but
I
guess
maybe
it's
better.
If
I
share
my
screen-
and
I
show
you
guys
what
I
was
working
on-
it's
it's
another
one
of
those
rabbit
holes.
I
was
working
on
another
issue
that
led
me
to
this.
So.
D
C
Well,
I'm
working
on
an
issue
that
has
sort
of
like
introduces
new
things
in
the
form,
api
and.
C
That
I've
been
sort
of
like
working
towards
is
the
inline
form
errors.
So
all
these
issues
that
I've
been
finding
recently
are,
you
know,
rabbit
holes,
things
that
I
there
are
either
direct
or
indirect
blockers
to
the
things
that
I'm
working
on,
but.
D
C
Yeah
this
one
has
to
do
with
form,
validation
and
odd,
odd
things
or
or
we're
trying
to
make
the
ux
better
in
certain
forms,
and
we
are
using
certain
workarounds
I'll,
better
share.
My
screen
bear
with
me.
C
So
this
has
to
do
with.
Can
everyone
see
my
screen
yep?
So
this
has
to
do
with
an
issue
that
robert
raised
recently.
Please
ignore
any
debug
messages,
I'm
still
working
on
things
just
to
improve
the
chrome
configuration
page
right,
so
this
has
to
do
with
ux,
as
in
making
it
less
confusing
to
understand
what
options
people
have
when
it
comes
to
to
configuring,
how
kron
runs
on
their
side
right
and
I
provided
a
mock-up.
So
the
the
issue
that
robert
raised
initially
was
to
improve
the
text.
C
So
I
created
a
a
meta
issue
which
says:
yes
improve
that
text,
but
also
maybe
do
other
things
like
group
things
together
in
field
set
like
I've
done
here.
C
Field
sets
and
sort
of
like
in
its
field
set,
have
a
distinct
option
and
some
help
text
and
possibly
links
to
documentation,
which
I
I
think
that
improves
the
situation
and
then
maybe
I'll
just
for
context
I'll
spin
up
a
a
demo
site,
while
that
that's
happening
in
the
background,
we'll
wait
just
to
see
what
the
before
and
the
after
was,
and
then
I
I
reached
the
point
where
one
of
the
options
for
cron
like
what
I've
done
here
is
I've
split
the
options
for
chrome,
because
we
are
using
arbitrary
and
hard
coded
values,
so
I'll
split
the
the
hard
coded
sort
of
like
drop
down
into
a
number
field
in
a
drop
down
field
which
provides
more
flexibility.
C
What
I've
also
done
is
I've
used
this
sort
of
like
pattern
where
we
sort
of
like
I'm
just
calling
it
natural
talk,
sort
of
like
interaction
with
the
user.
Instead
of
putting
these
these
fields
separately,
we
just
sort
of
like
have
a
sort
of
like
a
phrase,
and
then
we
have
form
elements
inside
that
phrase,
and
this
is
not
the
only
place
where
we
use
that
successfully.
C
C
So
if
I
got
a
configuration
and
then
it's
system
chrome,
so
this
is
basically
the
before,
and
this
is
the
after,
like
what
I'm
aiming
for
as
an
improvement
right
now
this
this
thing,
I
find
it
to
be
a
much
better
interaction
than
this
thing,
run:
chrome,
never
or
arbitrary.
You
know
values
that
we
have
here,
but
while
I
was
working
more
on
it,
I
realized
that
how
we
achieve
this
kind
of
interaction
with
the
user
is
by
using
prefixes
and
suffixes
for
the
fields.
C
C
But
if
you
translate
the
whole
phrase
the
ago,
suffix
in
other
languages
might
need
to
go
here,
which
is
a
prefix
for
this
form
element.
So
what
I've
been
trying
to
do
was
to
actually
render
this
as
a
single
markdown
field
and
have
these
be
placeholders
within
that
markdown
field,
and
these
placeholders
would
basically
render
the
field
elements
and
if
you
just
allow
me
to
uncomment
a
few
things
on
the
code
and
refresh
the
page,
bear
with
me.
C
Just
ignore
the
the
error
messages
for
now
so
and
this,
which
is
basically
my
working
around
of
plural
right.
I
have
a
solution
for
that.
C
But
my
point
is
that
the
elements
now
this
this
is
a
single
phrase
in
a
t
function,
so
I'm
getting
the
the
elements
to
render,
but
there's
no
default
values
in
them
and
then
there's
state
doesn't
work
because
the
name
attribute
has
not
been
attached
to
any
of
the
elements
and
what
I'm
using
here,
I've
tried
both
render
and
backdrop
render
within
t
and
outside
of
the
and
I've
realized
that
these
functions,
when
you
individually
try
to
render
elements
in
a
form
they
skip
setting
some
attributes.
C
C
This
works
beautifully
as
in
when
there's
a
single
value,
instead
of
plural,
it's
minute,
instead
of
minutes,
so
everything
becomes
similar
using
states.
So
this
is
where
I'm
trying
to
get
to
sort
of
like
have
a
more
natural
language
in
the
ux
of
setting
these
things
and
then
also
trying
to
make
it.
You
know,
be
a
consistent
thing
for
other
places
in
the:
u
ui,
where
we
use
this
pattern
so
yeah
I
haven't
pushed
any
code
yet
anywhere.
C
C
C
So
my
my
goal
was
to
basically
use
the
t
function
with
placeholders,
but
the
placeholders
instead
of
being
variables,
are
renderable
form
api
elements,
and
this
is
what
is
not
working
at
the
moment.
Maybe
I'm
just
trying
to
do
something
that
was
not
meant
to
be
done,
but
most
likely
that
but
yeah
all
right.
Joseph.
C
C
C
Yeah
anyways,
first
of
all,
the
feedback
that
I
want
is,
and
maybe
I'll
push
this
in
the
pr
so
that
people
can
play
with
it.
First
of
all,
do
people
find
these
sort
of
interaction
better,
because
I
I
get
annoyed
by
this.
This
sort
of
thing
like
we
have
this
drupalism
and
backtropism,
where
we
say
select,
never
or
you
know,
add
the
keyword.
Never
if
you
want
this
disabled,
whereas
we
do
have
a
proper
way
to
do
that,
and
it's
doing
that
right.
C
C
Yeah
and
if,
if
we
need
to
save
a
single
file
value
as
in
save
zero
zero
minutes
as
an
interval,
we
can
do
it
in
a
validation
or
a
submit
function.
We
can
still
save
zero
as
a
value,
but
the
thing
is
that
the
ui
doesn't
have
like.
We
don't
have
to
burden
the
users
with
developer
stuff.
That's
that's
where
I
was
getting
it.
B
C
B
B
G
Also
have
developer
tools
to
be
able
to
set.
Well,
I
guess
not
sorry,
I
would
say
this
greg.
I
really
like
as
well
what
you're
doing
here-
and
this
is
a
thousand
percent
better
and
I
would
say,
if
you're,
getting
really
hung
up
on
this
last
piece.
You
know
it.
It
feels
like
perfection
is
getting
in
the
way
of
yeah
yeah.
If
you
can,
if
you
can
get
this,
for
this
last
form
element
to
be
a
reasonable
proximity
right.
Maybe
it
won't
completely
work,
but
but
let's
get
this
out
the
door,
because
it's
great.
C
So
I
started
by
saying
this:
allow
more
flexibility
in
hardcoded
values
just
in
general
right.
C
Maybe
it's
better
to
see
that
and
I'm
I
haven't
raised
this
issue
yet
it's
sort
of
like
I'm
working
on
it,
but
but
what
I
was
getting
at
is
that
maybe
we
can
get
that
in
and
this
will
not
be
a
you
know
an
odd
thing,
because
we
do
we're
doing
it
here,
but
now
I
I've
seen
that
these
are
fragment
fragments
of
t
functions
and
I
was
trying
to
translate
them
in
greek,
and
I
saw
that
you
know
in
some
languages.
C
C
As
you
said,
it's
probably
I'm
going
to
leave
it
as
is
now
with
fragments
of
ts
as
in
used
as
prefixes
and
suffixes,
but
then
raise
this
as
a
follow-up
issue
to
figure
out
a
way
to
do
it
properly
and
then
list
the
places
where
we
need
to
revisit.
So
I
think
most
likely
we're
probably
going
to
do
that
so
yeah
anyway.
So
I'm
going
to
stop
sharing.
C
C
Well,
if
anyone
I'll
probably
get
those
things
I'll
file
a
pull
request,
so
people
can
test
things
and
then
I'll
file
that
that
follow-up
issue.
So
we
can
see
what
we
can
do
in
the
future.
D
Does
anybody
else
have
anything,
so
we
yeah
we,
I
I
we've
talked
so
much
about
it.
I
don't
want
to
talk
about
pageless
nodes
until
we've
got
everything
else
covered
and
also
that
could
be
an
either
meeting
so.
C
Yeah
is
there
any
progress?
Any
blockers
in
that
team
were
you
waiting
just
for
text
sort
of
like
input
from.
D
Others
feedback
there's
a
discussion
about
it,
but
I'm
going
to
hold
off
a
minute.
Anybody
else
have
anything
else.
A
5405,
it
really
just
boils
down
to
what's
the
right
term
that
we
should
use
everywhere,
for
is
it
a
url
alias
or
is
it
a
path
alias
because
both
are
in
the
documentation?
A
And
it
would
be
nice
to
you
to
mean
that
one
thing
and
it
would
be
nice
to
use
the
same
term
everywhere
and
there's
contradictory
answers
to
that
sprinkled
throughout
the
past,
so
it
would
be.
I
was
hoping
we
could
kind
of
get.
C
A
Is
this
is
actually
in
core
in
that
first
issue?
There's
61
path,
alias
187,
url,
alias
and
that's
all
in
core
code,
and
so
it
looks
like
url.
Alias
is
the
dominant
thing
and
that's
consistent
with
that.
First
comment
of
4868,
which
is
from
jim,
so
it
looks
like
the
preponderance
of
evidence,
is,
is
url,
alias
except
there's
still
well.
There
was
some
there's.
There
was
some
post
commentary
suggesting
url.
A
A
That
we
actually,
I
couldn't
tell
whether
we
really
did
have
a
defined
answer
so
yeah,
and
I
just
I
just
like
to
get
a
defined
answer
and.
C
My
only
because
I
haven't
thought
it
properly
until
now,
my
only
thing
is
so
concern
is
that
do
we
have
conflicting
things
when
we
mention
these
terms,
or
do
they
both
refer
to
the
same
thing?
Are
we
100
sure
that
they're,
referring
to
the
same
thing,.
D
A
Yeah,
but
but
everything
where
we
use
the
the
two
words
together,
url
alias
seems
to
be,
I
mean
I
haven't
actually
looked
at
all
187
examples,
but
it
seems
to
be
everywhere.
We
use
the
term
url
alias.
We
are
referring
to
what
is
called
elsewhere,
a
path
alias
and
so,
for
example,
on
yeah
just.
C
G
I
can
only
think
of
one
place
where
there
is
a
difference,
and
that
would
be
when
you're
looking
at
file
paths,
paths
for
where
public
files
and
private
files
and
temporary
files
are
set,
though
that's
actually
a
path
alias,
which
would
be
potentially
in
the
server
root
rather
than
in
the
installation,
and
so
that
is
a
path
alias
but
you're
right.
The
url,
url
aliases
are
all
for
the
aliasing
and
redirects
and
all
those
operations
on
the
site.
C
G
C
C
So
the
portion
of
that
entire
thing
is
a
path
alias,
but
if
you
put
it
together
with
the
prefix
of
the
domain,
is
basically
a
url,
yes
from
an
end
user
perspective
from
the
database
from
from
the
database
perspective,
we're
always
saving
paths,
we're
not
saving
url
aliases.
That's
my
understanding.
Unless
we're
linking
to
external
things,
which
is
the
redirects
that
we
were
saying
before.
E
Right,
it
isn't
isn't
this
a
cultural
gap
between
site
building
and
module,
developing
right
cause
like
from
the
perspective
of
a
site
builder
when
you're
building
things
for
people
using
out
on
the
internet,
you're
constructing
urls,
but
like
once
it's
inside
the
system,
it's
actually
not
a
url
anymore.
That's
about
the
the
http
is
gone.
It's
now
a
path.
So
so
it
is
it.
You
know
at
different
parts
in
this
life
cycle.
It's
both
things
like
I.
E
A
One
of
the
things
I'd
like
to
do
in
the
documentation
is
is
have
a
page
that
talks
about
all
the
different
kinds
of
path,
I'm
in
the
developer,
documentation.
It
has.
It
talks
about
all
the
different
kinds
of
paths,
because
we
have
a
bunch
of
them
and
it
would
be
nice
to
be
able
to
say
this
term
means
that,
and
it
might
be,
that
this
term
could
mean
a
or
b,
but
we
shouldn't
have.
E
B
B
A
There
are
menu,
router,
pads
and
book
menu,
just
talks
about
path
in
an
unqualified
way,
and
I
think
it's
acceptable
if,
in
the
con
to
use
unqualified
path,
if
the
context
implies
a
particular
kind,
because
because
the
paths
that
go
into
hook,
menu
are
sort
of
these
oddities,
where
the
percents
can
be
followed
by
an
entity
name,
you
know
percent
node
and
though,
and
that
kind
of
never
shows
up
anywhere
else.
C
E
E
It's
a
technical
acronym
but
yeah
and
you're
making
assumptions
of
technical
knowledge
there.
My
grandmother
knows
my
grandma's
dead.
My
mother
knows
knows
the
word.
Url
would
not
know
what
a
path
is,
so
you
know
the
the
further
out
there,
but
but
but
then,
if,
if
it's
incorrect
so
so
it
seems
reasonable
at
any
given
usage
to
say
you
know
if
it's
at
the
brink
to
go
for
the
simplest
one.
That's
not
incorrect.
C
Yeah,
I
would
say
so
long
as
we
don't
make
things
confusing.
We
can
use
them
in
the
interchangeably
if,
if
one
thing,
one
of
the
two
things
means
something
specifically
under
certain
circumstances,
what
I
don't
want
us
to
get
into
is
another
layout
and
layout
template
situation,
so
we
decided
that
the
things
are
going
to
be
this
called
layouts
very
early
on
when
we
couldn't
anticipate
the
disambiguation
between
you
know,
layouts
and
layouts
templates.
That's
what
I
would
like
us
to
you
know
not
get
into
other
than
that.
A
E
A
C
Yes,
yeah
you're
right,
that's
where
the
issue
the
problem
is
like.
If
we
get
confused,
then
yeah
people
that
are
new
to
backdrop
all
together,
yeah
yeah,
so.
A
It
sounds
like
it's
gonna
break
existing
code,
though
right
no,
no.
This
is
all
in
documentation.
It's
all
in
code,
names
and
comments,
not
don't
change
any
variables,
don't
change
any
function,
names
all
right,
just
in
the
in
the
documentation
of
code
that
shows
up
in
functional
descriptions,
but
then
that
will
also
propagate
into
human
readable
documentation.
A
C
Gonna,
it's
gonna
propagate
to
things
that
are
in
t
functions,
so
contra
translatable
strings
that
we
communicate
to
people.
D
D
C
Yeah
or
maybe
update
the
issue
summary
and
say,
as
you
said,
the
contenders
are
bullet
points.
This
means
that
this
means
that-
and
this
means
that
and
then
actually
actually
mention
if
these
are
mental
sort
of
like
connection
things,
that
we
are
making
up
to
explain
things
or
if
they
are
actual
things
right,
I
think
that
it
would
make
as
in.
Are
we
making
things
easier
for
people
to
read
or
understand,
whereas
in
a
developer
language
it
would
be
called
something
else
or
that's
what
we
actually
call
them?
C
B
Well,
well,
I
mentioned
that,
but
what
robert
said
in
his
issue
is
actually
alias
path,
because
in
core
we
actually
refer
to
every
like
in
code
everything's,
like
router
path,
menu
path.
It's
always
like
some
qualifier
underscore
path.
C
C
We
might
tweak
it
further
to
even
remove
certain
items
from
it,
but
we
need
them.
You
know
in
the
issue
summary,
I
think
so
that
we
can
make
a
decision
and
if
we,
if
you
can
put
examples
either
in
code
or
what
we
call
them
in
the
database
and
then
the
ui
or
the
documentation,
then
that
would
be
perfect.
D
Okay,
ari,
we
can't
be
more
clear
yet,
but
I
don't
certainly
have
opinions
on
this,
but
we
got
about
15
minutes
left
in
this
meeting
a
few
days
before
future.
Freeze
now,
for
those
just
to
clarify
future
freeze
on
sunday
means
no
new
features
in
backdrop.
We
can
continue
to
make
us
ux
and
design
changes
through
january
15th.
D
So
a
lot
of
the
ux
issues,
we're
talking
about
probably
aren't
affected
by
the
deadline
on
tuesday,
but
one
that
would
be
would
be
the
the
new
note
or
the
new
pathless
nodes.
D
So
does
anybody
have
any
other
issues
that
are
blocked
that
you
need
need,
help
that
are
blocked?
That
would
be
affected,
especially
by
the
deadline
on
friday
or
on
sunday.
Just.
A
C
Yeah,
so
so
we
can
merge
them
if
they're
like.
If
there's
things
like
you
know,
we
need
to
tweak
the
wording.
We
can
still
mess
them
because
we
have
another
two
weeks
to
fix
that
as
a
follow-up
issue.
So
in
other
words,
what
I'm
saying
it's
if
it's
a
huge
feature
that
makes
a
difference
and
we're
just
stuck
on
making
decisions
on
what
we're
going
to
call
things,
we
can
still
merge
them
and
then
make
a
decision
later.
We're
not
going
to
hold
back
issues,
features
that
are
95
or
98
done.
C
That's
what
I
was
getting
at,
but
but
after
the
the
feature
freeze,
anything
that
is
tagged
with
the
label
type
feature
request
cannot
be
merged.
That's
that's
it.
Please.
No
only
only
bugs
and
tasks
which
are
follow-up,
follow-up
tasks
can
be
sorry,
things
that
you
need
to
add
to
it
to
feature.
Requests
that
have
been
recently
merged
can
be
follow-up
tasks,
so
they
are
labeled
as
tasks.
A
D
Good
excellent,
I
know
there's
there
is
always
some
a
little
bit
of
confusion
about
this
at
the
end,
and
tests
would
be
required
before
we
can
merge
something
right.
So
we
can't
a
functional
new
feature
that
needs
tests
has
to
have
them
by
someday
right.
C
Yeah,
usually,
usually
it's
a
core
decision.
If
it's
a,
if
it's
a
complex
feature
that
we
better
have
tests
along
with
it,
a
core
committer
may
block
it
and
say
sorry:
it
can't
get
in
because
it
doesn't
have
any
tests,
but
sometimes
we
we.
If
this,
if
it's
a
small
thing
either
we
rush
fix
the
test.
Oh
sorry,
at
the
test
last
minute,
or
we
just
merge
it
and
then
follow
up
with
tests.
C
Okay,
so
that
has
happened.
Okay,
yeah,
but
it's
an
exclusion.
It
has
to
be
like
a
tiny
feature.
Thingy,
it's
not
if
it's
a
huge
feature
like
I
don't
know
many
mini
layouts
in
core,
then
it
definitely
needs
tests.
That's
what
I'm
saying
yeah!
I
understand
yeah.
Okay,
what
I've
done
is.
I
I
filtered
all
the
the
issues
by
the
next
milestone.
C
C
I
don't
see
anything
that
that
is
tagged
as
ux
and
has
you
know,
needs
feedback
or
needs
work
at
the
moment
right
but
yeah,
but
if
you
guys
filter
do
the
same
and
filter
that
if
anyone
is
working
on
any
of
those
issues
and
needs
feedback,
just
let
us
know,
because
what
I'm
getting
at
is
that
some
of
them
might
be
ux
issues
they're,
just
not
tagged
as
that.
D
Okay,
well,
let's
we
could
go
ahead
and
talk
about
the
pageless
notes
and
I
can
describe
where
we're
at
yeah.
Let
me.
D
Let
me
do
a
quick,
I
have
a
site
set
up
and
I
just
got
to
make
it
quick.
D
Okay,
so
where
this
is,
the
issue
is
at
one
I
haven't
had
time
to
to
work
on
it
this
week,
like
I
hope
so
we're
not
where
we
hope
to
be
also
for
a
reason.
I'm
a
little
confused
by
this
doesn't
look
right,
but
it's
good
enough.
Let
me
try
this
one
more
time
was
this.
D
D
I
forget
why
this
this
is
broken,
but
anyways.
It
doesn't
matter
for
the
discussion
where,
where
somebody's
keyboard
is
really
loud,
a
little
bit,
it's
you,
okay,
the!
What
am
I
saying?
Okay,
so
where
this
is
hung
up
on
was
about
a
well.
I
think
the
the
biggest
issue
is
whether
or
not
to
leave.
This
is
a
view
right
now,
a
view
of
three
cards
and
like
one
of
the
problems
we
were
having
was
getting
the
cards
to
display
in
the
right
order.
D
Apparently
when,
as
far
as
I
could
tell
when
tugboat
generated
the
cards,
it
generated
them
at
exactly
the
same
time.
So
my
d,
I
I
had
ordered
the
cards
by
you-
know
time
of
creation,
but
which
was
working
fine
locally,
but
when
tugboat
created
the
site,
it
had
them
in
reverse
the
opposite
order,
and
the
only
explanation
I
had
was
that
the
time
wasn't
different,
so
it
was
it
it
sorted
them
in
a
different
order.
D
Now
we
we
thought
about
fixing
this
by
using
some
other
value
to
to
change
their
order
to
the
order
we
wanted.
But
then
doc
wilmond
pointed
out
something
that
has
been
discussed
before,
which
is
a
view
is
really
not
the
most
natural
way
to
create
this
feature.
This
feature
is
really
about
three
kind
of
existing
nodes
on
the
front
page,
which
could
better
be
handled
really
in
the
layout.
D
We
did
not
originally
use
a
layout.
You
know
by
a
layout
I
mean,
for
example,
three
regions
right.
We
could
have
a
a
row
with
three
regions
in
it
and
put
one
existing
node
in
each
one,
and
then
we
have
complete
control
over
it.
I
think
that
is
a
more
logical
way
that
a
beginner
might
build
something
like
this,
but
it
also
adds
complexity
and
right
now
we
can't
do
that
with
our
existing.
D
Probably
the
other
option
might
be
to
have
three
existing
nodes
that
are
just
themed
to
you
know
to
to
to
appear
in
three
columns
but
they're,
actually
in
one
region
that
doesn't
seem
to
me
to
be
I
you
know
it
seems
to
me.
If
we're
trying
to
make
this
simple
and
understandable
to
users,
we
would
go
with
three
separate
regions,
but
yes,
we
can't
do
that
with
boxton,
so
we
we
would
have
to
create
a
new,
and
I
think
I
didn't
get
a
chance
to
test
this,
but
from
comments
that
I
well.
D
I
did
some
really
brief
testing
based
on
comments
from
olaf.
We
may
not
be
able
to
to
accomplish
this
goal
with
an
existing
layout,
so
we
we
might
actually
have
to
create
a
new
layout
or
I
don't
know
if
somebody
if
anybody
else
has
an
idea
on
how
we
could
create
this
with
an
existing
layout.
C
C
D
We
might
be
here,
we
might
be
able
to
use
geary.
The
problem
is
we've
modified,
boxton,
boxton
normally
doesn't
let
you
have
a
who
would
a
full
width
thing
in
it,
so
we've
already
modified
that
in
basis,
so
that
it
allows
a
full
width
top.
I
think
right,
it's
header
top
and
then
content,
so
the
top
has
already
been
modified
by
boxton.
D
So
if
we
used
geary
for
sure
we
would
have
to
make
that
same
change
in
boxton.
Also,
I'm
not
quite
sure
what
change
like
the
three,
the
three
columns
we
would
actually
want
them
to
have
a
content
class
on
them,
which
that
might
not
be
a
problem.
D
I
don't
know
we
might
be
able
to
make
geary
work,
but
it's
going
to
involve
some
playing
around
and
that's
I
had
hoped
to
have
a
better
sense
of
exactly
what
would
be
involved,
and
I
don't
have
that.
So
what
I
think
I'm
looking
for
right
now
is
feedback
on
one.
How
to
make
this
work,
or
is
this
too
big
a
deal
go
ahead?
Are
you
creating.
A
D
A
second
that's
all
that
problem
is
solvable.
That's
not
that
sort
of
led
us
to
this
discussion
about
layouts,
but
then
the
discussion
about
I
mean
I
think
some
people
have
been
asking
that
question
even
before
that
issue-
and
you
know
I
I
think
the
thought
is
that
the
layout
using
a
layout
is
a
better
solution
for
this.
D
C
Yeah,
so
so,
basically,
instead
of
using
a
view,
we
use
node
blocks
right,
yeah,
suggesting
node
box
yeah,
so
we'd
have
three
blocks
with
existing
nodes
and
and
ideally
would
place
places
block
in
a
separate
region.
We'd
already
have
three
columns
there
right.
I
think
that
would
be
ideal.
C
B
I
think
this
might
be
just
because
of
the
way
the
kind
of
sites
I've
worked
on
in
the
past,
but
I
think
I
would
definitely
I
would
have
definitely
gone
with
a
view
for
this.
B
Non-Pageless
nodes:
I
mean
that
that's
not
a
factor.
B
B
D
Well,
okay,
automatically.
I
I
definitely
see
where
there
are
use
cases
where
a
view
makes
sense.
I
think,
as
has
been
discussed
in
anything
like
this,
we
have
to
be
sort
of
opinionated
and
I
think
the
use
we're
envisioning
a
kind
of
a
common
use
case,
which
is
that
this
is
about
three
blocks
on
the
front
page.
So
it's
not
about
10
000
nodes,
it's
not
that
that
isn't
possible.
D
C
Require
those
yeah.
The
other
thing
is
that
I've
heard
if
I'm
correct,
I
think
jen
mentioned
it-
that
we
already
have
a
an
example
usage
off
of
you
in
the
homepage,
which
is
basically
the
promoted,
content
and
well.
D
Of
an
example
of
a
view
with
only
one
node
doesn't
make,
isn't
a
very
good
example
of
views.
So
I
added
a
second
post.
So
then
we
had
three
existing
nodes
and
we
had
two
posts
and
then,
when
I
showed
that
to
people
the
feedback
was
that's
too
much.
We
don't
want
that
much
content
on
the
front
page,
let's
make,
and
so
we
actually
consciously
decided
to
make
the
cards
a
view,
because
we
didn't
want
that
much
content.
C
Later,
no,
no,
you
were
right.
You
convinced
me
actually,
because
what
we
have
is
an
example
of
a
view
with
a
single
entry.
So
it's
not
it's
not
out
of
the
box.
It's
not
like.
We
know
that
it
is
a
view
and
people
that
know
how
to
use
views
right.
They
understand
the
value,
but,
yes,
all
right
cool.
So
what
so?
Again
now
that
you
have
explained
this,
what
is
the
problem
with
using
a
view
for
the
cards
like?
What
is
the
argument
against
it?
Well,.
D
There's
the
the
the
what
initiated
the
discussion
was.
We
had
some
problems
with
ordering
that
problem
is
solvable.
We
can
solve
that
problem,
but
that
just
triggered
a
discussion
that,
if
you
would
I
I
think
doc.
Wilmont
has
most
forcefully
made
this
argument,
but
most
of
the
rest
of
us
have
agreed
that
for
a
beginner,
the
the
the
use
case
that
we
were
trying
to
formulate
makes
much
more
sense
to
most
of
us
as
three
existing
content
blocks
right.
D
It
can
be
done
with
views,
but
that's
adding
complexity
that
maybe
isn't
necessary
here,
and
it's
maybe
counter
to
our
goal,
which
is
you
know.
A
pageless
node
in
a
block
was
kind
of
our
that
was
sort
of
the
original
use
case
for
a
pageless.
Node
right
is
you've
got
a
block
and
you
just
want
to
drop
a
page,
an
existing
node
into
that
block,
and
I
think,
most
of
the
time
you
wouldn't
do
that
with
the
view.
So
can.
E
E
Is
is
a
good
approach
because
that's
kind
of
what
people
are
looking
for
when
they're
when
they're
thinking
about
how
am
I
gonna
do
my
home
page?
How
am
I
getting
my
about
page?
How
am
I
gonna
do
like
the
first
simple
pages
when
they
get
to
later
all
right?
How
am
I
gonna
do
the
10
000
student
pages?
E
Then
then
it
won't
take
them
long
to
find
view
and
be
like,
oh
that
solves
that
great,
like,
I
think,
that's
kind
of
a
natural
progression
in
azure
site
scales
and
I
think
it's
very
natural,
but
but
I
I
I
I
think
I
think
it's
good,
that's
something
like
this,
but
I
mean
I
think
this
is
gorgeous.
I
mean
it's
a
very
pretty
like.
Oh
my
god.
That's
that's
what
I
want
that's.
I
can
do
this.
Let
me
just
change
the
pictures
change
the
text,
publish
it
call
grandma.
D
D
Okay,
so,
okay,
it's
almost
at
three
o'clock,
the
other
thing
even
prior
to
prior
to
this
discussion
of
layouts.
D
This
this
feature
is
going
to
break
concrete
themes
and
what
I
had
hoped
to
do
by
this
week
was
have
a
list
of
all
the
concrete
themes
that
would
be
broken
and
we
could
decide
whether
or
not
we
thought
contrib
theme
maintainers
would
have
time
to
fix
them
in
the
next
two
weeks.
We
don't
really
want
to
release
a
new
feature
on
the
front
page,
that's
going
to
break
contrib
scenes,
and
but
there
was
some
discussion
and
we
tentatively
decided
last
week
that
maybe
we
should
postpone
this
to
the
next
release.
D
Get
this
as
one
of
the
first
commits
to
1.22
and
that
this
whole
layouts
thing
sort
of,
I
think,
was
leading
us
also
in
that
direction.
If
we're
going
to
do
if
we're
going
to
add
a
layout,
there's
more
chance
of
there
being
bugs
or
problems
that
we
haven't
anticipated
in
trying
to
force
that
in
in
the
last
couple
of
days,
especially
with
this
other
problem,
maybe
doesn't
make
sense.
C
Yeah
can
we
can
we
discuss
the
problem
with
contributing
the
next
meeting
the
dev
meeting,
because
we
need
to
stop
this
one?
What
I'm
thinking
is
how
we
handle
updates.
So
I
was
about
to
ask
a
question,
but
which
is
related
to
what
you
were
saying:
how
does
an
existing
website
backdrop
website
react
to
a
core
update
if
installed,
themes
and
modules
depend
on
a
previous
version.
C
So
if,
if
existing
projects
themes
declare
a
dependency
on
the
existing
version
of
a
backdrop
core
that
doesn't
include
this
feature,
how
would
the
backdrop
side
react
to
the
existence
of
the
update
of
the
new
version?
Would
it
block
the
new
version
being
installed
and
deal
this
is
handled,
because
that
could
be
a
solution.
I
mean
because.
B
D
F
D
Yes,
okay,
everybody
thanks
for.