raspberrypi / scratch

Scratch releases
79 stars 21 forks source link

Saving project seems to make comment tiles grow a little bit #195

Closed timrowledge closed 8 years ago

timrowledge commented 8 years ago

From the forum - "by iw1 » Mon May 23, 2016 6:45 am

A minor bug that I've noticed recently in scripts that include comments: when the screen is redrawn after the file is saved, each of the comment boxes is slightly wider than before the save. Not a problem, just a minor irritation if you do a succession of saves and are trying to maintain a layout free of unnecessary scroll bars."

Seen in the may 2016 system; seems to add a couple of pixels (perhaps a blank space width?) on saving. If reading the project back in it appears to have been saved in the file.

timrowledge commented 8 years ago

Example, showing the growth, made by screens hotting and overlaying; the upper section of the image is after the save. scratchcommenttile

timrowledge commented 8 years ago

I used this bug as an example whilst talking about debugging at my local Makerspace last night. It is an interesting problem because the trigger - saving a project - is one of the few places where you can't easily debug in the usual Smalltalk way; the process of converting the project into a form for writing to a file is done in an "interesting" manner that puts the system into a state that just breaks the UI if you try to halt in a debugger. Ouch!

However, some code peering and digging suggested that the comment morphs are created correctly sized and get resized after the save is completed. It looked like things ought to be ok since the size was being recorded correctly and re-set to that same value but the inner text morph (that is the actual comment text) was getting resized in such a way that it made the wrapper (the main ScratchCommentMorph) grow by 4 pixels in width. It turned out that the AlignmentMorph we wrap the text morph and the resize-handle morph in is defaulting to use an item inset of 2 pixels... suspiciously like our problem size growth.

So, making the alignment morph use a 0 inset is good in this case and makes the growth anomaly go away. However, to add fun to my daily life, it also seems to interfere in the corner rounding used to make the comment's final shape. Ah, well, baby steps...

timrowledge commented 8 years ago

Can't believe how much pain that was to sort out. A change in the architecture of how corner rounding is done was behind the drawing problem, and a reasonable temporary solution has been found. It ought to be updated some time to make clean fix.

timrowledge commented 8 years ago

Fixed in NuScratch-tpr.354