text inputs have larger areas than builtins

[ToonTalk]

E.g.

seems OK while

leaves lots of white space.

Shouldn't custom blocks look the same as builtin ones?

[jmoenig]

for primitives I'm only ever using the input slot type "any" instead of "text". Personally, I have never liked the "text" type input slots, don't know why we even have them.

[brianharvey]

This is entirely my fault.

If you look at the Scratch collection of primitives, all of the text related ones come with default input values such as "hello " and "world," whereas all of the numeric ones don't. There are also a few cases in which any input is okay, such as ADD [ ] TO list. So I thought that input slots that expected text strings were wider than input slots that didn't care! So when planning out the long-form input dialog, I had a Text input type and an Any input type. (I do know, and did even then, that numbers are also strings, as in Logo.) I don't recall Jens trying to talk me out of it.

I could be talked into getting rid of Text type, as long as we don't break old code, which I guess means converting Text type inputs to Any type when loading a project.

Maybe if we spec out the User-Defined-Type input type in time for 7.0 we can put that one in place of Text in the dialog. :)

[ToonTalk]

There are also a few cases in which any input is okay...

I think now with hyperblocks all (or nearly all?) text oriented blocks accept lists. split and length of text for example. So now even sentence to list accepts lists.

Before hyperblocks I might have tried to defend the 'text' type but not so much now.

[cycomachead]

I think there are plenty of cases where text is the only logical input -- so I think it perhaps has a value in theory. However, I think given there's no intuitive distinction between text and any, and no practical input differences that Snap! offers, I think it could make sense to remove.