I don’t use Blockly, I only have a vague idea that it’s a concept where you go through a lot of trouble to not have to write code.
I’m trying to make the block library editor support “read-only” block libraries, that for example are provided with a YAML file. The whole idea is that if you open a “read-only” block library, you shouldn’t be able to change anything, only view/copy. I’ve managed to handle the text editor pane and the “preview” pane (I think) so that you can’t modify anything there. But, then there’s this “Preview” button that opens a pop-up dialog. I have no idea what’s what between the previews, what I do know is that if I try to make the “preview pop-up” read-only, it only shows a blank canvas. The “toolbar” on the left disappears, and there’s nothing left. So, it seems useless.
My question is, what is this dialog for, what can you do there, and is there any meaningful way to make it work in “read-only mode”? Or should the button simply be hidden for read-only libraries?
actually not. It works very well for rules up to a medium size. I really like it because I can create rules on the couch with just the phone. Writing JavaScript on the phone without a proper editor doesn’t really work.
It shows under “this library” how the blocks look like in the library of the rule editor.
I don’t think this makes a different for editable/non-editable block libraries. There is nothing editable in this view anyway, but as pointed out, it shows how the content of the library looks like in the blockly rule editor libaries side menu.
I do use Blockly myself for many of my rules as it is much more self documenting for the uneducated person. My rules: option 1 use rule actions without any scripting at all, option 2 use Blockly if anything is missing (in the end it generates js), option 3 use javascript if it becomes too wieldy or complex. I see Blockly as more accessible then using js directly. But all of that is also personal taste.
I see the “phone-aspect”. I rarely use a phone for anything but calling, so it’s not a relevant situation for me. I do have a laptop available from the couch though
As I said, I don’t understand this screen, but: From the popup dialog, you can change numbers and whatnot, and that makes the library “dirty”. Whether that’s “real” or not I have no way to verify, but it gets dirty and will warn you if you try to leave without saving. There is a change listener attached to the popup dialog that I assume registers changes and “transfer them” to the parent page.
If you look at the screenshots in the PR, I did come up with “something” eventually:
I still don’t know if it makes sense though, but it’s at least not editable.
Indeed, I see the behaviour. But it doesn’t make sense to me. In the preview you can build a test rule (it is the Blockly rule builder), and this would make that rule dirty, but there is no way to save the rule only the block library. It can be useful to inspect the generated javascript when building a block. I would think this dirty state for the preview window should not propagate to the block library editor.
It didn’t make sense to me that changes to the preview would make it dirty either, but it does, so I made this “dead” preview where you can only see the blocks. This could/should probably be figured out by somebody that understands Blockly, I just did the best I could with my very limited understanding.
The preview pane on the right shows you what the block will look like in isolation. The preview button lets you actually use the block and see what JS code gets generated.
There are two parts to creating a block library. You need to create the blocks themselves with the sockets and plugs and all that stuff. And there is the JS code that gets generated by the block.
The preview pop-up cannot be made read only. As you identify, it would be completely pointless and you don’t actually change anything in that pop-up anyway. You just test out what the block can do. So that preview dialog either needs to remain as it is, or completely removed. If you can’t change the library anyway there’s little point in testing it out in the preview pop-up.
To test your block in a context with other blocks and see that the JS rendered is correct.
No. It should either work as it does now or be completelty removed (hide the button). My recommendation is to leave it as is as it doesn’t hurt anything be being enabled.
You can’t actually change anything in the preview dialog anyway. So it’s already read only from that perspective.
That’s a bug. There is nothing you can change about the library itself in the preview pop-up. All you can do is test out what’s already defined. It should not bemarked dirty from the preview pop-up under any circumstances.
That is pointless. Remove the preview button. A pop-up where all you can do is see what the block looks like among the other blocks but not actually use it and see how it interacts with the other blocks and review the JS that is generated completely obliterates the whole purpose of that preview pop-up. Better to not have it at all.
The “correct” solution would be to fix the bug that is causing the library from, being marked dirty in the first place. If for some reason someone is creating a block library from scratch using a YAML file, they still need a way to test it out and see how it interacts with the other blocks and what JS it generates.
I think I’ve found why it gets dirty (“the bug”) and as far as I can tell, I’ve verified that nothing you do in the preview window will actually change the block library, so I think I can just remove the code that sets the dirty indicator when the preview is changed, and then let the preview have the same functionality regardless of read-only status of the block library.
