I think the font size of the block’s comment is too small.
So it’s hard to read. Can I change the font size of the Comments?
1 Like
For a workaround in Windows, I use the Windows+ and Windows- magnifier keyboard control.
1 Like
You can also use the zoom buttons in the bottom right of the workspace!
I wonder if the problem is actually the font color is a bit light, which makes it harder to read on the yellow background. It looks like the designer css may be infecting the comments. Thank you for pointing this out @Semicolon, I’ll have to look into it
3 Likes
So here’s a comparison between the current text color and a “fixed” text color.
Current:
Alternate:
@Semicolon do you think that solves the problem? Or do you think the font size should be increased as well?
Anyone who has thoughts please feel free to respond! @ABG could I tap you for an opinion as well?
2 Likes
The two options as presented were both at my personal resolution limit (my eyes are old), but the AI2 zoom button did a fine job of expanding the text, better than the Windows magnifier.
One color option was a bit darker than the other, but hardly more readable at that resolution.
I would regard comment font size a non-issue, compared to expanded comment bubble default hang location distance, typically far off-pane when the comment’s parent block is in a more than a few blocks long sequence.
There is an entire category of old people jokes about low hanging body parts, equivalent to the work of trying to grab and elevate AI2 comment bubbles.
1 Like
Oh, Zoom is the best way to do it. Thank you all!
1 Like
I think changing the text color is good, too.
1 Like
I’m with ABG on this. Better to have a look at the vagaries of the comment box:
- Disappears off screen when clicked if blocks are long
- When Do It called again on an open comment, the comment box is moved back to it’s opening position, doesn’t stay where it is, and also goes to the end of the text, rather than showing the latest entry at the top, meaning you have to resize the box to see the latest entry. ( I can sort of see the reason for showing the history…)
1 Like
The comment bubble might better be thought of as a comment balloon, to get the metaphor of its tether being a string that could be dragged to reel in the offscreen balloon. The tether is already wide enough to grab.
(I fear this would be in Blockly, not in AI2.)
1 Like
Oh, and they move all over the place when you close and restart a project.
1 Like
Thank you for the feedback! I think I'm going to switch it over to the darker color (if the maintainers agree) 
This is really good to know! I actually fixed this in blockly core a while ago. I changed bubble behavior so that bubbles try to stay as close as possible to their icon. Here is a video of the current behavior in core. I'd also like to highlight this point in the video specifically, because I think it showcases how bubbles still avoid overlapping the block they are attached to.
Note that the demo is of mutators, but the functionality applies to comments as well.
Do you think behavior like that could work @TIMAI2 @ABG ? (Others are welcome to reply as well!) I haven't checked, but it shouldn't be too hard to move that functionality into app inventor.
The only problem would be weighing adding it against the costs of upgrading it later.
That sounds pretty annoying. I'm not sure if I'll be able to keep the comment from scrolling to the end of the text. (There's not really support for moving the text programmatically). But I'll look into it!
And (from what I know of AI) I think the comment bubble moving when it shouldn't can definitely be fixed.
Ok, that's really weird. The positions of the comments should be serialized to XML. (maybe that's not included in AI's version of Blockly?) I'll look into it!
Thank you guys for all of the feedback! I've added these tasks to my project list. If I create github issues for them I'll be sure to post links here, so you can follow the progress if you want 
3 Likes
I think I have a handle on how the comment bubble is behaving, and how to work around its behavior. Here’s a video of my AI2 comment bubble behavior test, given what I learned in the Blockly test bed mutator test video. …
Bottom line:
The bubbles (mutator and comment) try to avoid the screen edge, based on which quadrant of the workspace window holds the mutator (or comment) icon.
The bubbles also try to avoid the body of their block, when deciding how far to go from the base icon.
In the case of a procedure or event block, or any sizeable control block, if you have positioned the enclosing block to allow you to read its code (a natural impulse), that sends the comment block downwards, offscreen.
The comment block adds insult to injury (injury to insult?) by knocking the workspace pane off its scroll bar when it pops up below the view screen. Strangely, the mutator does not do this (thank you.)
So my new-found workaround is to position the parent block into the lower half of the workspace viewport before opening a comment block.
If I were to summarize the least possible change to the pop up positioning code, I would add the requirement anywhere but downwards .
2 Likes
So important things first:
- I fixed the comment text color in #2179. That change should go out with the next release of AI.
- I opened up issue #2180 for making comment positioning better. In it I outlined two options. Option 1 is based on saving the position of the bubble, so that if you move the comment it stays there. Option 2 is based on making comment positioning smarter so hopefully you don't have to move your comments.
If you have a preference between those two options feel free to comment here or on the linked issue. Input is always appreciated
Also note, in my previous post I said:
I was wrong about that : / Comment positions get saved for workspace comments (which don't exist in AI). They do not get saved for block comments. Adding that should definitely be doable if that's the route we want to go though.
Now to respond to your feedback:
My pleasure! It's super cool to to work on a project where I can just talk to people and see what they feel should be fixed
Sounds right to me! I should have linked to the relevant code in my previous response. I don't know if you're interested or not, but here's the PR that added the smarter positioning if you want to take a look.
2 Likes
Thanks for looking into this.
I have too little experience with Javascript’s canvas equivalent to check code correctness on this, but I would be happy to test a server instance.
1 Like
This seems reasonable as long as the X, Y that we save is relative to the block X, Y. Blockly already saves the width and height of the comment bubble, so it seems reasonable to extend with x and y as well.
1 Like
Awesome! In all honestly I'm not sure if I have the ability to do that lol. But if that becomes a possibility I'll definitely shoot you a link.
Absolutely! We would definitely want it to be relative to the block, because otherwise we'd end up with the same problem of comments being super far away. It might be funny, but not very fun lol.
The only problem I see with adding this feature is that we would lose the ability for the comment to position itself intelligently. The two features are kind of mutatually exclusive:
- Either the comment is positioned statically based on where the user puts it.
- Or the comment is positioned dynamically based on where it would be most visible.
We can't really get both 
So it just depends on what users of AI would prefer.
2 Likes
I can live with intelligent placement, but the best of both worlds can be achieved if the comment remembers whether or not was ever repositioned in its lifetime.
Regarding testing, here’s a critical test …
Position the parent block in the workspace window so that there’s no margin around it, and see if the comment bubble is smart enough to see that there’s no escape for it, so it might as well just center itself in the visible window.
When I read the new code, I did not see an explicit test for this case (unless it was covered by min() and max() calls.)
2 Likes
They aren't necessarily mutually exclusive in the sense that we could intelligently position the bubble unless the user has moved it, in which case we save the user's preference. The user moving it out of the way suggests that the intelligent placement wasn't the best and the new location should take precedence.
Another thought I just had: What if there was also an intelligent placement based on the user information. For example, if I have previously positioned the comment and it is closed. I open the comment, but it would be positioned off of the screen. The comment intelligently moves back into the viewport, but only temporarily, and keeps itself within the viewport until its original bounds are fully within the viewport, at which point it stops trying to adjust itself. This way if the user is just moving through the workspace comments aren't randomly moving around, but if you just open a comment it is still fully visible. Internally we'd need a way to say that the position information is temporary and shouldn't override the user-specified position.
2 Likes
You are correct! Currently that case isn't handled because the core team didn't want that to be an option. But personally I think that would would be a good option to have!
Before I respond to your point (which I think is a good point!) I just want to clarify the current core behavior a bit.
So (speaking about comment bubbles specifically) the bubble gets a chance to intelligently itself if and only if it is being opened.
This means that the comment does not move itself if it is already open, even if it goes off screen:
And it means that if you close the comment, move the workspace, then reopen the comment, it could show up in a different position:
You guys probably already understood that, but I wanted to clarify anyway.
So back to your comment:
I understand where you're coming from. Having two separate states for the comment: one where it has been manually positioned, one where it hasn't, seems to blend the two differen options together nicely.
My only concern is it doesn't seem to really take advantage of the intelligent positioning system. If the intelligent positioning messes up once, it never gets a chance to try again. Do you kinda get where I'm coming from?
I like this behavioral option much better. It solves the problem of comments getting opened off-screen, which I think is important to fix. The only problem I see with this is the implementation. Currently, there are no workspace drag events. And block drag events aren't much better: they're only fired once the block has been dropped. So figuring out a way to implement this might be tricky.
But like I said, I do think this would be a cool way for bubbles to work!
1 Like