Replies: 3 comments 1 reply
-
|
Hmm one problem: providing an inline bsn list is now ambiguous with providing a single BSN: // before
bsn! {
Node [
{children}
]
}
// after
bsn! {
Node
// this expects an `impl Scene` not an `impl SceneList`
{children}
} |
Beta Was this translation helpful? Give feedback.
-
|
Here's a random shower thought: define the entire hierarchy upfront, and then create the specific entities directly at their correct level. Just spitballing here! bsn! {
{
bg
bg_top
bg_top_label
bg_checkbox
bg_bottom
},
bg{
Node { width: px(100) }
BackgroundColor(GREEN)
}
bg_top{
Node { width: px(10) }
BackgroundColor(RED)
}
bg_checkbox{
: checkbox
InteractionDisabled
Children[
Text("Hello there")
]
}
bg_bottom{
Node { width: px(10) }
}
}
bsn! {
{
*bg
**top
***top_label
**checkbox
**bottom
},
bg{
Node { width: px(100) }
BackgroundColor(GREEN)
}
top{
Node { width: px(10) }
BackgroundColor(RED)
}
checkbox{
: checkbox
InteractionDisabled
Children[
Text("Hello there")
]
}
bottom{
Node { width: px(10) }
}
} |
Beta Was this translation helpful? Give feedback.
-
|
@cart Here's an alternate proposal, in three parts. The first part doesn't address the children ambiguity, but it does deal with the over-indentation, and avoids the "XML uncanny valley" effect. The idea is to use the YAML / Markdown page break token bsn! {
Node { width: px(100) }
BackgroundColor(GREEN)
[
Node { width: px(10) }
BackgroundColor(RED)
---
:checkbox
InteractionDisabled
Children [
Text("Hello there")
]
---
Node { width: px(10) }
]
}In effect, the triple-dash token is functioning as a comma, but it looks better when appearing on a line by itself than a naked comma. Note that I'm not completely enamored of this syntax, but I like it better than For the children ambiguity, I have an even more radical suggestion, but it will require some context. Several suggestions for resolving the "children" ambiguity have involved making the initial token more than just a single Up to this point we've mostly been discussing the "leaf-level" BSN syntax: the examples are mostly concentrated on defining individual entities and components, and while there are some inherited scenes there are relatively few. However, my vision, for UI anyway (and possibly other things) is that we'll have a rich set of inheritable scenes and mixins, and that users will mostly be working at that level: that is, most of the syntax will be a composition of mixins and inherited scenes, with actual raw components and relations being the minority case. This means that I want to optimize BSN syntax for that mode of authoring. In particular, one thing that happens quite a lot at higher levels of abstraction is the frequent use of embedded :listview(
bsn_list! [
:listrow [(Text("First World") ThemedText)],
:listrow Selected::default() [(Text("Second Nature") ThemedText)],
:listrow [(Text("Third Degree") ThemedText)],
:listrow InteractionDisabled::default() [(Text("Fourth Wall") ThemedText)],
:listrow [(Text("Fifth Column") ThemedText)],
:listrow [(Text("Sixth Sense") ThemedText)],
:listrow [(Text("Seventh Heaven") ThemedText)],
:listrow [(Text("Eighth Wonder") ThemedText)],
:listrow [(Text("Ninth Inning") ThemedText)],
:listrow [(Text("Tenth Amendment") ThemedText)],
:listrow [(Text("Eleventh Hour") ThemedText)],
:listrow [(Text("Twelfth Night") ThemedText)],
]
)Here we are passing in the contents of the listview as a template parameter rather than using the children syntax. The reason we have to do this is because listview has a more complex internal structure: it has an outer "frame" element which holds the scrollbars, and an inner "scrolling" element which contains the actual rows. Thus, the actual row entities are the grandchildren of the Similarly, in my bevy_reactor experiments, I use if_then_else(
|cx: &Cx| *cx.resource::<State<GameState>>().get() == GameState::Play,
|| bsn_list![Text("Yes: Playing")],
|| bsn_list![Text("No: Not Playing")]
)The So one idea would be to define a shortcut. The most obvious is to simply delete the word :listview(![
:listrow [(Text("First World") ThemedText)],
:listrow Selected::default() [(Text("Second Nature") ThemedText)],
:listrow [(Text("Third Degree") ThemedText)],
:listrow InteractionDisabled::default() [(Text("Fourth Wall") ThemedText)],
:listrow [(Text("Fifth Column") ThemedText)],
:listrow [(Text("Sixth Sense") ThemedText)],
:listrow [(Text("Seventh Heaven") ThemedText)],
:listrow [(Text("Eighth Wonder") ThemedText)],
:listrow [(Text("Ninth Inning") ThemedText)],
:listrow [(Text("Tenth Amendment") ThemedText)],
:listrow [(Text("Eleventh Hour") ThemedText)],
:listrow [(Text("Twelfth Night") ThemedText)],
])(BTW note that the So now we have created an association in the user's mind between the token :listview(![
:listrow ![(Text("First World") ThemedText)],
:listrow Selected ![(Text("Second Nature") ThemedText)],
:listrow ![(Text("Third Degree") ThemedText)],
:listrow InteractionDisabled ![(Text("Fourth Wall") ThemedText)],
:listrow ![(Text("Fifth Column") ThemedText)],
:listrow ![(Text("Sixth Sense") ThemedText)],
:listrow ![(Text("Seventh Heaven") ThemedText)],
:listrow ![(Text("Eighth Wonder") ThemedText)],
:listrow ![(Text("Ninth Inning") ThemedText)],
:listrow ![(Text("Tenth Amendment") ThemedText)],
:listrow ![(Text("Eleventh Hour") ThemedText)],
:listrow ![(Text("Twelfth Night") ThemedText)],
])Combining this with the :listview(![
:listrow ![Text("First World") ThemedText]
---
:listrow Selected ![Text("Second Nature") ThemedText]
---
:listrow ![Text("Third Degree") ThemedText]
---
:listrow InteractionDisabled ![Text("Fourth Wall") ThemedText]
---
:listrow ![Text("Fifth Column") ThemedText]
---
:listrow ![Text("Sixth Sense") ThemedText]
---
:listrow ![Text("Seventh Heaven") ThemedText]
---
:listrow ![Text("Eighth Wonder") ThemedText]
---
:listrow ![Text("Ninth Inning") ThemedText]
---
:listrow ![Text("Tenth Amendment") ThemedText]
---
:listrow ![Text("Eleventh Hour") ThemedText]
---
:listrow ![Text("Twelfth Night") ThemedText]
])What about regular relations? If we use the bsn! {
Node { width: px(100) }
BackgroundColor(GREEN)
![
Node { width: px(10) }
BackgroundColor(RED)
Owned [
Mutable(true)
---
Reaction(false)
]
]
}I realize that this argument is on fairly weak ground: that purely in terms of semantics, the association between children and other relations is stronger than the association between children and template parameters, and my syntax is inconsistent with this. However, we're working in a highly constrained space here and don't have a lot of options, so I'm willing to live with a little bit of inconsistency for pragmatic purposes. OK to sum up, I have laid out three proposals, which can be adopted (or not) individually:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This is a potential alternative BSN syntax that attempts to resolve some issues with the current BSN syntax. It comes down to introducing new
<>syntax to indicate the bounds of an Entity.First, here is an example with the current
bsn!syntax:And here is the
<>syntax:Resolved Issue: Over-indentation / newlines
In the current syntax, children with more than one component use
()for clarity. This sadly results in both over-indentation and unnecessary newlines:The proposed
<>syntax resolves these problems:Resolved Issue: Eliminates the
RelationshipTarget []vsComponent []ambiguityThe current
[]shorthand forChildren []creates ambiguities withSomeParentComponent []andRelationshipTarget []. This new syntax removes the[]shorthand, freeing upRelationshipTarget [](if we still want it in this new world ... coming up a with a new syntax might be better).Resolved Issue: Syntax Noise
Currently defining children involves a mix of
[],(), and,:<>syntax cuts this down substantially:Resolved Issue: Child misalignment
Currently for terseness, children don't require
()wrappers for small numbers of components:This makes it visually challenging to pair
#Child1and#Child2together.<>syntax would be required, which forces a "pairing" between them:Resolved Issue: Where to put commas
The current BSN syntax has rules that feel a bit "arbitrary". Components within a single entity do not use comma separators, lists of entities do:
Some people find this confusing / arbitrary.
<>removes the comma case from the "structural BSN syntax", reserving it only for initializing rust types:BSN currenty exists in a middle ground where it largely feels like Rust, but it makes targeted departures from Rust syntax in the interest of ergonomics or clarity. This creates a kind of "wait why aren't there commas here" discomfort in some people, as it feels like a violation of Rust-like expectations (ex:
(Node Marker)when defining a child entity instead of(Node, Marker)). Adding commas to that case feels ergonomically non-viable to me in the context of BSN.The proposed
<>helps resolve that discomfort by more fully decoupling ourselves from the Rust context.<>feels less "Rust-ey" and more "user-interface-ey". When defining hierachies in<>elsewhere (ex: the web), people expect no commas:We're just replacing these attributes with components (and abandoning the "closing" aspect of XML):
Resolved Issue: Removes an annoying "syntax refactor" case
Currently, adding a component can force a move from the "shorthand" approach to the
()wrapper approach:With
<>syntax, this is not necessary:New Issue: What do we do for custom relationships?
Previously, all "hierarchical relationships" felt the same:
We will almost certainly lose that pairing in the new world, and are likely to lose the "shared levels of indentation".
New Issue: XML / HTML similarity
<>introduces a similarity to XML / HTML that may cause some developers to wrongly assume they are compatible. I personally think this is worth it.Note that I think embracing more XML syntax would make things worse (ex: "closing syntax like
</div>" or<button />syntax would degrade our ergonmics)Alternative: Use
()instead of<>Pros:
Cons:
Losing special "entity syntax" means it is harder to pick out entities / children from other rust code. Everything starts to blur together. Consider this:
Perhaps too Rusty ... people expect to use commas inside
()I'm personally still biased toward
<>.Beta Was this translation helpful? Give feedback.
All reactions