--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAOk7GcTYLq2ERy52mHxMMJ0RHR3y5d4f%2BLzjjMCJy6T4XB1%2BZA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAEBzR94AaRCEybyk3XT0Dy07eNCEvjRva3fe%3DYyJp6Dfu1%3D9uA%40mail.gmail.com.
I think the problem is with using makeConnection_ :/ If you check that docs that's a protected function which isn't intended to be called by external developers. All of the public functions try to protect you from having both an output and a previous connection, which is an invariant that Blockly expects.I believe the reason that this is an invariant is because handling both types of connections on a single block adds the possibility of circular connections, which adds a lot of additional complexity to Blockly. But again, I don't remember the exact context here.
> And if previous+output connections are intended to be disallowed, why not next+output connections?The way I think of it is that these two pairs of connection types are associated:output : previousinput : nextPrevious connections are often used to model "outputs" in situations where you can have a variable number of inputs. For example, open roberta uses statement inputs to model variable declarations, which are very similar to outputs:As such we treat previous connections as passing information "up" to the parent block, the same way that outputs pass information "into" the parent block.Next inputs act the opposite way, accepting information, in the same way that input connections do.Granted this is pretty confusing because the visualization of the connections makes it seem to be the opposite, but this is how it works internally.
I hope that kinda helps? But it's confusing to be honest haha. Happy to talk about it more if you have other thoughts!
--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/4ff52268-324f-415c-814f-436a8e850433n%40googlegroups.com.
Now some musings:- Representing a block with an ignorable return value feels tricky on a user interface level. How do you give feedback to a user that they must disconnect their previous connection before connecting the output? Does your block have both all the time, or change its rendering as you drag? The ternary block is an example where it may change types--and disconnect blocks--in response to blocks being dragged near it, and it feels like everything has exploded if you don't know why that's happening. Same thing with figuring out how to heal stacks, show insertion markers, etc.
--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAFE_sBE3kyS9au1%2BLeZWrn1%3DLGme%3D55fL4KUP6NZtMEO%3DqTN5w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/50d3148e-022b-4138-b9b4-c32c817f615fn%40googlegroups.com.
> I think the ternary block (I assume you mean IIF() / ?: by this) isn't really something we need to worry about. It's one thing to have a block that has both top and left connections. It's another to have an INPUT that can ACCEPT both value and statement blocks in the same connection. I see no reason to support the latter; that WOULD be more confusing. And since a conditional block that returns a value would accept values, and a conditional block that acts as a statement would accept statements, it stands to reason that you would have two separate blocks for the task even if "chameleon" blocks were to exist.
The ternary block is relevant here because its connections change in response to what is being dragged to it. The changes are to connection type instead of connection existence, but it's still a good case to look at since those changes sometimes cause it to spit out already connected blocks. Since insertion markers are actual blocks that are connected during a drag and then disconnected as the dragging block moves away, there's some tricky undo/redo behaviour for those rendering changes (referred to as "healing the stack" in code).
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/f9c9fdb0-5c99-47c5-8b82-b197c2548ad3n%40googlegroups.com.
> I think the ternary block (I assume you mean IIF() / ?: by this) isn't really something we need to worry about. It's one thing to have a block that has both top and left connections. It's another to have an INPUT that can ACCEPT both value and statement blocks in the same connection. I see no reason to support the latter; that WOULD be more confusing. And since a conditional block that returns a value would accept values, and a conditional block that acts as a statement would accept statements, it stands to reason that you would have two separate blocks for the task even if "chameleon" blocks were to exist.
The ternary block is relevant here because its connections change in response to what is being dragged to it. The changes are to connection type instead of connection existence, but it's still a good case to look at since those changes sometimes cause it to spit out already connected blocks. Since insertion markers are actual blocks that are connected during a drag and then disconnected as the dragging block moves away, there's some tricky undo/redo behaviour for those rendering changes (referred to as "healing the stack" in code).Well, that's what I'm saying -- if we're worried about things being confusing, I think that's the wrong design for a conditional block. Sure, having the same block definition work for both cases is fine, but I think that having statement-if and expression-if being a single block in the toolbox that dynamically mutates back and forth based on its children is probably not the best idea.
It doesn't make sense to me to have an input that can be either a value input or a statement input.
They're not even rendered the same way!
Values go inside the body of the block; statements go in the cavity of a C shape.
On Mon, Nov 1, 2021 at 10:13 AM Coda Highland <chig...@gmail.com> wrote:> I think the ternary block (I assume you mean IIF() / ?: by this) isn't really something we need to worry about. It's one thing to have a block that has both top and left connections. It's another to have an INPUT that can ACCEPT both value and statement blocks in the same connection. I see no reason to support the latter; that WOULD be more confusing. And since a conditional block that returns a value would accept values, and a conditional block that acts as a statement would accept statements, it stands to reason that you would have two separate blocks for the task even if "chameleon" blocks were to exist.
The ternary block is relevant here because its connections change in response to what is being dragged to it. The changes are to connection type instead of connection existence, but it's still a good case to look at since those changes sometimes cause it to spit out already connected blocks. Since insertion markers are actual blocks that are connected during a drag and then disconnected as the dragging block moves away, there's some tricky undo/redo behaviour for those rendering changes (referred to as "healing the stack" in code).Well, that's what I'm saying -- if we're worried about things being confusing, I think that's the wrong design for a conditional block. Sure, having the same block definition work for both cases is fine, but I think that having statement-if and expression-if being a single block in the toolbox that dynamically mutates back and forth based on its children is probably not the best idea.Just to be clear, that's not what the current ternary block does nor is it what I am proposing. I am proposing a block which indicates that it can act as either a statement or an expression depending on where it is placed, not what it's children are. That said, I don't really see anything wrong conceptually with having the latter, though I can't quite come up with a reasonable use-case off the top of my head ;-)
--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/427f6cd1-723f-4328-83e3-d96acf5c2116n%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/mmZcSqoGun8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAFE_sBEy7KXmtre1FoG%3Dc0v060DF%2BbnFDLxbO1Jn%2Bn_1Doe02Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAK1VB9sdO_bpf3U%3D195cOZNpXT1UczY9%3DqADBbQsSO09iGx-Kw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAOk7GcTNcKd6u5FS%2BbqMn116YTbmj%2Bt1q%2BXETRvJwHUmcg3U1Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAFE_sBHJVeiM%2BVwV1SCqZObLjLj%2Benparf9Rk0DkRd9m8Zxh0A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAOk7GcTHyEiLrOmqz1HQhbd-x_FxApc1T2wmR9u%2BPYsg-Nb3wQ%40mail.gmail.com.