Multiline Text with comment demo - not sure about language files, help e...

[starfishmod]

Here is multiline text for blockly -
I have also added a comment block type and made it work with the code demo
please note I was unsure what to use in the setHelpUrl and tooltip in the text_comment I added in blocks/text.js

I welcome any feedback and corrections. As always you will need to run build.py before use

Andrew

[JustusW]

Why is this not merged yet? I love it!

[starfishmod]

Can i get get some feed back on this? If there is a problem or the code is not up to scratch please let me know?
Thanks

[carlosperate]

/* */ don't work in python, you need """ """ instead.

[carlosperate]

I haven't really tested this pull request, and even though it is not the main part, I don't really see much point to add a comment block when any block can have comments attached to it without having to take space in the workspace.
I have also added a comment to the code.

[starfishmod]

Thanks for the feedback! - I'm not a python coder so I will fix. I guess the comment block was to show how it works - happy to remove that part. That being said I prefer the comments in a block as it means I can read the comments in the blocks without actually having to click and open to read.

[JustusW]

I used this block to create a native language block to help on the way of two ways parsing between python and blockly. Works as expected, I did not find any bugs so far.

[carloslfu]

The textarea field could be very useful for custom blocks.

[starfishmod]

@NeilFraser Can I get some kind of feedback on this pull request and the JSON import/export pull requests? Both requests seem to be things that myself and other people want, both have been here for a while and there has been no response so far.
Please may I have some feedback?

[toebes-extreme]

I've gone ahead and taken the effort to merge the code from this into the latest Blockly version (#103) but am losing the battle with merging it into this pull request.

[starfishmod]

@toebes-extreme I honestly don't mind what version of this goes into blockly and I appreciate your effort to keep with this version though. This has been sitting here for almost 6 months without a comment or reason for not including this from @NeilFraser. I can only hope you have better luck than I getting something merged.

[toebes-extreme]

I was hoping to try to get my changes put on top of this version, but I've not figured out how to merge the request into this one so that there is no confusion about the pedigree of the change... Any advice or hints as to how to get the merge pulled in so we don't have two requests would be greatly appreciated...

[acbart]

What is holding back this pull request? It seems like a nice feature to have in the main.

[carlosperate]

If you guys don't mind, I'd like to express my opinion on this.

I haven't actually tried this pull request, so please correct me if I am wrong, but the way I see it, this only displays a message as a block (which then can be used to add code comments). It does not actually do anything, there is no action, nothing to step through, it's just a comment. Taking in consideration that you can already add comments to blocks, this does not really feel like "part of the language", all the blockly blocks are logical statements and this breaks that pattern.

The current comment system allows you to have a message opened or closed (which is set in the xml, so if you want to load the program with the comment opened, you can) in any position around the code, and very clearly marking where it belongs without disrupting the code flow. If some message related to the program, but not specifically related to a single code block, is important enough to be highlighted, then I think an overlay popup similar to what is used in blockly games (https://developers.google.com/blockly/hacking/mistakes#6_instructions), makes a lot more sense. These popups can clearly mark visually the context of the message and exactly to what it is referring, it does not disrupt the program flow and it can react to specific actions.

If a blockly user needs to include a message, I fail to see in which scenario this would be more beneficial than the current comment system.

[acbart]

I don't see tremendous value in having it used for comments either. The big deal for me is to have embeddable code literal snippets and multiline string values. You can see the former in action in my project here (check out the "Calculation" tab, the "Code Block" block)
https://dl.dropboxusercontent.com/u/23141976/blockpy/blockpy.html

Embedding code seems to be one of the best ways to transfer students out of blocks into text . Weintrop[1] has started publishing some results on this that are quite promising.

[1] David Weintrop. 2015. Minding the Gap Between Blocks-Based and Text-Based Programming (Abstract Only). In Proceedings of the 46th ACM Technical Symposium on Computer Science Education (SIGCSE '15). ACM, New York, NY, USA, 720-720. DOI=10.1145/2676723.2693622 http://doi.acm.org/10.1145/2676723.2693622

[carlosperate]

Well, that kind of implementation would still break the philosophy behind blockly (https://developers.google.com/blockly/about/language), and creates very tight coupling with a targeted language generator.

That being said I can see the usefulness in some cases, however, what would be the difference between that and just creating a block with:

this.appendDummyInput()
    .appendField(new Blockly.FieldTextInput("default"), "NAME");

(In an unrelated note, @acbart when I tried your example I got TypeError: Blockly.getAbsoluteXY_ is not a function)

[acbart]

I sort of see what you mean by breaking the philosophy, but I don't think that's necessarily the case. If you explicitly labelled it as "python code block" or "XML code block", then it will lead to a tight coupling - but if you just leave it as a general purpose block, it's up to a (transferring) learner to write what they want. Of course, I'm biased since my project is all about creating a tight coupling with Python :)

As for the difference: it's the FieldTextArea, which is multi-line. You can't do multiple lines in a FieldTextInput, unless I missed something in the latest version.

PS: Thanks for trying out my project, it's been partially broken since the newest release. I've been updating the code today, which is why all this is on my mind. That particular error has been fixed, but there's still so much to do...

[carlosperate]

The way I see it, if a block introduction into the code demo app (https://blockly-demo.appspot.com/static/demos/code/index.html) breaks any of the code generators resulting in the production of invalid code (even if it passes all unit testing), then it shouldn't be included into the core blockly.

However, I don't see anything wrong with updating FieldTextInput to allow multi lines, and then leave to the hands of developers the creation of their own blocks in whichever way that fits their needs.

All in all, it would interesting to hear from @NeilFraser.

[starfishmod]

@carlosperate My main aim was to get the core/field_textarea.js committed as it's a function I am using. Currently there is no way to do multiline text in the current textInput. I don't care if it is my code or if it comes from someone else.

The comment block was a way of showing it works. I personally don't care if that is included or not into the main code base.
However on that note I have to see I dislike Blockly's way of hiding comments in blocks. If I'm looking at a large block there is no way to read the code + comments together. I have to click each block (I'm not outputting to other languages) to see what someone's reasons or thoughts are.

Yes it would be interesting to hear from @NeilFraser as this seems to be a fairly popular requested item and people are using it in their own projects.

[acbart]

I've found a bug I can't crack with this code.

If you use this block with some text and load the page, it works fine initially.

However, if you hide the Blockly canvas and then restore it (as I do in my application frequently), then its width is set to 0.

As far as I can tell, when it rerenders after the first time, the blocks haven't been drawn on the screen so the usual getBBox/getComputedWidth/etc. functions all return 0.

I have no idea what to do about this, but fortunately it's not a game breaking bug. Still, it looks messy. You can see it for yourself here:
http://think.cs.vt.edu/blockpy/lti_tool?name=breaking_width.py

[gfwilliams]

Is there a solution for multi-line text areas now? This page implies there isn't: https://developers.google.com/blockly/guides/modify/future

And this code no longer works on the latest versions of Blockly

[JustusW]

It's a 3 year old pull request mate. This is probably never coming to blockly.

[acbart]

I don't know how many versions behind the main branch we are now, but BlockPy uses this solution still, and there aren't any problems. In fact, we even discovered how to fix the zero width issue we were having before (we were making our own problem by loading blockly offscreen).

Link to our implementation: https://github.com/RealTimeWeb/blockpy/blob/master/blockly/core/field_textarea.js

[gfwilliams]

@acbart sounds like you're in the same situation as me then! I'm using this and so can't upgrade - your version still has the createSvgElement call which is one of the things that fails for me on the newest Blockly.

I thought upgrading Blockly would fix the zero width issue I was having as well, but it doesn't... It was the same offscreen issue :) It looks like I'll be sticking with the older Blockly version for now in order to keep using textarea :)

[acbart]

Comparing the two implementations of createSvgElement, it doesn't look like they changed too much:

New: https://github.com/google/blockly/blob/master/core/utils.js#L290
Old: https://github.com/RealTimeWeb/blockpy/blob/master/blockly/core/utils.js#L326

They got rid of an unused parameter, and they moved the function inside the utils package. I believe it wouldn't be too hard to update the code. Unfortunately, I won't have free time until the summer to fix my own version.

[gfwilliams]

Thanks! It's be great if you could post here if you do have success with it. I'd be kind of confused if they didn't merge a new PR in given the admission that it's one of the most-requested Blockly features.

Honestly, I think I must have messed up. I swear I did a text search in blockly_compressed.js and never found a mention of createSvgElement - but it's definitely there :) I just did a quick test - using your code and:

Blockly.createSvgElement -> Blockly.utils.createSvgElement
Blockly.addClass_ -> Blockly.utils.addClass
Blockly.removeClass_ -> Blockly.utils.removeClass

It's 99% there. The only thing obviously missing is it's not displaying the initial text from the constructor

[starfishmod]

I'd be happy to update this PR (again) but only if I know that this is indeed still requested AND the developers are keen to add it :) @acbart I would probably use any improvements you have put into yours (or base it on your version) if that is cool? I have kept my own copy up to date as well but it may be a bit rough around the edges :P

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot. The email used to register you as an authorized contributor must be the email used for the Git commit.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[starfishmod]

I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[gfwilliams]

Well, I'd really appreciate it - I imagine @acbart and me can't be the only two people using this... I've been using it in https://www.espruino.com/ide/ pretty much since you posted it - for over 3 years now!

[acbart]

@starfishmod Please feel free to use whatever code from my version you want. It'd be nice if this made it into the main product some day...

[rachel-fenichel]

Hey folks,

It sounds like this is an important feature for you, and we're definitely interested in having it in Blockly. No one on the team has extra cycles right now, so one of you will need to implement it. Here are the steps you'll need to take:

• Make a version of this pull request against develop
• Make FieldTextArea inherit from FieldTextInput, or explain why that doesn't work
• Remove the comment block from this PR
• Add a block that uses this field to the playground, and create generators for it in all of our languages

The playground block should look similar to the current text block. Instead of an open quote before the text and a close quote after, it should have a paragraph symbol before the text and no symbol after.

When you have a pull request that meets those criteria and passes review we can add this feature to the core library.

Longer term, multi-line text areas are difficult because it's hard to know where to break the line.
It looks like this implementation breaks at every newline in the text, which means that a long paragraph just extends the width of the block endlessly. We'd like to avoid that by cutting off the line and adding an ellipsis (...) after a maximum number of characters. The user would see the full text when clicking on the text area, but not otherwise.
Obviously people will also want the current behaviour. We propose a property on the field to set the maximum number of characters before the ellipsis. If the parameter is set to Infiinity, the text is never shortened.
This can be done in a followup PR.

Cheers,
Rachel

[rachel-fenichel]

Also, if you're using Blockly and avoiding updating due to a missing feature we have no way to know. Please fill out the developer registration form to help us understand what features you're using and what features you need.

[starfishmod]

@rachel-fenichel Thanks for your input - I'll try and put something together over the next week or so (suddenly time poor again :) ). Unfortunately I don't know all the programming languages intimately to build every language - If I get stuck is that something that yourself or others could help with?

[rachel-fenichel]

@starfishmod sounds good. With respect to the generators for various languages: if you get stuck, send out what you have and we can ping the mailing list for help with any missing languages.

Fortunately multiline strings shouldn't be too bad to represent in generated code, as far as I know. Our issues with them are more around the UI.

Thanks!
Rachel

[rachel-fenichel]

I'm closing this pull request, but I look forward to seeing the new version.

[acbart]

What's the status on this now? I'm separating out the dual block/text editor from BlockPy this summer into a stand-alone component, and I'd hoped to use Blockly without forking it. I think this field type might be one of the only things preventing that. If I make a pull request per Rachel's directions, will it be accepted? It looks like the other folks never got around to making the pull request.