Create setter blocks that select from a list of values

[halatmit]

Implement property setters that choose from a selection of values. For example, the setter for screen.alignvertical should allow only top, center, and bottom. This could be implemented with a new kind of block that incorporates a dropdown. Make sure the dropdown uses the list-of-pairs method to accommodate internationalization.
Implement a new property editor type that generates this block from a list of values, coordinated with the way these appear in the designer.

We need to also keep the current version of the setters, for when the argument needs to be computed. We should probably make a way to morph one form to the other, or make selecting from the dropdown do the transormation between forms.

After this is done, we can update some of the existing setters so that they use this.

[halatmit]

This is the same as issue #155

[fmntf]

Hi! I would like to try to implement this, as it is already implemented in Espruino Web IDE. I need this in my fork.

Which Blockly version are we used? Is it clean or patched by the AI team?

[halatmit]

@fmntf @afmckinney @jisqyv @NeilFraser
Thanks for wanting to work on this. We have our own copy of the Blockly code here in the App Inventor source tree. We try not to modify our version of the Blockly core much, and Andrew periodically merges in the new Blockly updates from Neil.

There are some non-obvious aspects to what needs to be done here. For example, the block that sets the value of a property will mostly be choosing from a fixed set of values and the dropdown is perfect for that. But users also need the ability to set the property to the result of an expression, so a dropdown of fixed values is not sufficient.

[fmntf]

Hi @halatmit. Espruno propose a fixed list of values on a dropdown menu, but it allows to delete the dropdown and plug other blocks (like variables or procedure calls). See this screencast.

Do you think it would be enough?

[halatmit]

@fmntf
That looks very good. Your video doesn't show this working with external inputs, but I assume it does.
It would be great if you could finish this up and submit it as a pull request, so we can all play with it. thank you so much!

[fmntf]

Hi. As said in Google Groups I have started to implement this feature on the UDOO branch. You can see the result here.

Some useful features could be:

1. if I try to set an argument like pin/mode/value to color/list/something else invalid, the connection should be rejected;
2. if I connect a number/string i.e. to pin, the number/string block should be casted to the dropdown Blockly.Blocks['udoo_pinout'] type.

For 1), it is done in other parts, like logic_negate

Blockly.Blocks['logic_negate'] = {
  init: function () {
    ...
    this.appendValueInput('BOOL')
        .setCheck(Blockly.Blocks.Utilities.YailTypeToBlocklyType("boolean", Blockly.Blocks.Utilities.INPUT))
        .appendField(Blockly.Msg.LANG_LOGIC_NEGATE_INPUT_NOT);
  }
};

but I have no idea on how to do this on Blockly.Blocks['component_method'] since it is shared on all components methods. Any advice?

For 2), I did not find anything similar in AI. I tried add a changed listener but I don't know Blockly internals to go on. @NeilFraser do you have suggestions?

Thank you!

[fmntf]

Hi @halatmit @NeilFraser
have you got the chance to see my implementation?

I need some feeback to go on, to understand if I'm taking the right direction. Advices on how to implement some protection logic (see the first point in the previous post) are also welcome!

Thank you,
Francesco

[halatmit]

Franceso,

The video looks great. But it's hard for me to review the code unless you
submit it as a pull request, where you start building from the App Inventor
master branch, so we can pull down that branch and built it and run it.
Can you do that or do you have questions?

Paul: Comments?
Lyn: comments?

== Hal Abelson
hal@mit.edu
Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
MIT Media Lab, Second Class Faculty

On Tue, Jun 23, 2015 at 4:16 AM, Francesco Montefoschi <
notifications@github.com> wrote:

Hi @halatmit https://github.com/halatmit @NeilFraser
https://github.com/NeilFraser
have you got the chance to see my implementation?

I need some feeback to go on, to understand if I'm taking the right
direction. Advices on how to implement some protection logic (see the first
point in the previous post) are also welcome!

Thank you,
Francesco

—
Reply to this email directly or view it on GitHub
#195 (comment)
.

[mark-friedman]

I didn't see anything in the video showing the new property editor in the designer that you would use for specifying that this is an 'enum' type of property. You would associate that property editor with properties that want to use it via the editorType attribute of the DesignerProperty annotation on the property. Presumably in such an editor you would enable the user to specify a set of name/number pairs which would constitute the allowable dropdown options (i.e the names) and their corresponding numerical values. Once you know those you can do type checking and type conversions.

[paulmedwal]

Good job getting it this far. In the long run, it will be important that these blocks are generated based on information passed in from the designer. Creating lots of single purpose blocks like "arduino_pin_mode" and "arduino_pin_value" will be harder to maintain. Instead, as Mark said, marking properties as having drop downs, and using that drop down information to generate the block will make it possible to easily add these types of blocks for new components.

[fmntf]

Thank you for your feedback!

I think there are two different cases. The first is about properties values (and it is related to issue #195) - we should make users able to select properties values from the blocks editor.
The second case - the one I need for UDOO - is to let users provide correct arguments to methods calls. Those lists are only related to the blocks editor (so I wouldn't use DesignerProperty annotation, since there is no designer involved).

For properties values we should probably generate Blockly code starting from editorType.
For method arguments, we should probably create a new attribute in SimpleFunction, which automatically generates code like my arduino_pin_mode example.

[mark-friedman]

@fmntf

Maybe it's creating a separate issue which covers the work you are doing on functions, since issue #195 explicitly deals with properties.

[fmntf]

@mark-friedman I totally agree. I have created a separate bug: #432. Thank you!

[ewpatton]

I believe that the helper block functionality implemented by Beka addresses this issue.